[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1601082031070.3575@nanos>
Date: Fri, 8 Jan 2016 20:31:18 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Dave Hansen <dave@...1.net>
cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
dave.hansen@...ux.intel.com
Subject: Re: [PATCH 10/31] x86, pkeys: arch-specific protection bits
On Wed, 6 Jan 2016, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@...ux.intel.com>
>
> Lots of things seem to do:
>
> vma->vm_page_prot = vm_get_page_prot(flags);
>
> and the ptes get created right from things we pull out
> of ->vm_page_prot. So it is very convenient if we can
> store the protection key in flags and vm_page_prot, just
> like the existing permission bits (_PAGE_RW/PRESENT). It
> greatly reduces the amount of plumbing and arch-specific
> hacking we have to do in generic code.
>
> This also takes the new PROT_PKEY{0,1,2,3} flags and
> turns *those* in to VM_ flags for vma->vm_flags.
>
> The protection key values are stored in 4 places:
> 1. "prot" argument to system calls
> 2. vma->vm_flags, filled from the mmap "prot"
> 3. vma->vm_page prot, filled from vma->vm_flags
> 4. the PTE itself.
>
> The pseudocode for these for steps are as follows:
>
> mmap(PROT_PKEY*)
> vma->vm_flags = ... | arch_calc_vm_prot_bits(mmap_prot);
> vma->vm_page_prot = ... | arch_vm_get_page_prot(vma->vm_flags);
> pte = pfn | vma->vm_page_prot
>
> Note that this provides a new definitions for x86:
>
> arch_vm_get_page_prot()
>
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
Powered by blists - more mailing lists