kernel pages superpage promotion/demotion

[Alan Cox]

On 10/12/2015 18:39, suresh gumpula wrote:
> Thanks a lot for quick reply Alan.
> The super page promotion/demotion  of kernel allocations is done in
>  9.1 also  I assume .  Please confirm.
>

Yes.

> Regarding write protection,  I am trying to chase a corruption of uma
> zone allocation,  so I was looking at pmap_protect(9).
> And thinking of using something like  pmap_protect(kernel_pmap, sva ,
> eva, VMPROT_READ);  to write protect  sva to eva of a zone allocation
> return address.
> So  can  pmap_protect(9) be  used for this purpose ?
>

Yes.  However, you can't reenable write access, or in general upgrade
access, with pmap_protect().  You'll need to use pmap_kextract(),
PHYS_TO_VM_PAGE(), and pmap_enter() to recreate the mapping with write
access.

>
>
>
> On Mon, Oct 12, 2015 at 6:43 PM, Alan Cox <alan.l.cox at gmail.com
> <mailto:alan.l.cox at gmail.com>> wrote:
>
>
>
>     On Mon, Oct 12, 2015 at 3:11 PM, suresh gumpula
>     <gsuryacse7k at gmail.com <mailto:gsuryacse7k at gmail.com>> wrote:
>
>         Hi,
>               I understand that user space VM map pages dynamically
>         promoted/demoted to super page
>           if the kernel thinks that it gains the performance.
>                 The question is  , does this apply to kernel map pages
>         too ?
>
>
>
>     Yes, it applies to memory allocated for UMA zones, malloc(9), and
>     contigmalloc(9).
>
>      
>
>         And is it possible to write protect kernel address space VA with
>          pmap_protect(9).   Since the protection is per 4k page,  I
>         see this
>         routine tries to demote to 4k page.
>         Or this is only for user space maps to support  mprotect(2)
>         and gdb
>         watchpoints.
>         Do we have any other API to write protect kernel addresses
>         which come from
>         UMA zone allocations ?
>
>
>
>     No.
>
>     Can you please try to describe what are you trying to do at a
>     higher level?  
>
>