Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1686279

Re: [RFC v5 00/38] powerpc: Memory Protection Keys

Show all headers | View raw

On Thu 13-07-17 08:53:52, Benjamin Herrenschmidt wrote:
> On Wed, 2017-07-12 at 09:23 +0200, Michal Hocko wrote:
> > 
> > > 
> > > Ideally the MMU looks at the PTE for keys, in order to enforce
> > > protection. This is the case with x86 and is the case with power9 Radix
> > > page table. Hence the keys have to be programmed into the PTE.
> > 
> > But x86 doesn't update ptes for PKEYs, that would be just too expensive.
> > You could use standard mprotect to do the same...
> 
> What do you mean ? x86 ends up in mprotect_fixup -> change_protection()
> which will update the PTEs just the same as we do.
> 
> Changing the key for a page is a form mprotect. Changing the access
> permissions for keys is different, for us it's a special register
> (AMR).
> 
> I don't understand why you think we are doing any differently than x86
> here.

That was a misunderstanding on my side as explained in other reply.

> > > However with HPT on power, these keys do not necessarily have to be
> > > programmed into the PTE. We could bypass the Linux Page Table Entry(PTE)
> > > and instead just program them into the Hash Page Table(HPTE), since
> > > the MMU does not refer the PTE but refers the HPTE. The last version
> > > of the page attempted to do that.   It worked as follows:
> > > 
> > > a) when a address range is requested to be associated with a key; by the
> > >    application through key_mprotect() system call, the kernel
> > >    stores that key in the vmas corresponding to that address
> > >    range.
> > > 
> > > b) Whenever there is a hash page fault for that address, the fault
> > >    handler reads the key from the VMA and programs the key into the
> > >    HPTE. __hash_page() is the function that does that.
> > 
> > What causes the fault here?
> 
> The hardware. With the hash MMU, the HW walks a hash table which is
> effectively a large in-memory TLB extension. When a page isn't found
> there, a  "hash fault" is generated allowing Linux to populate that
> hash table with the content of the corresponding PTE. 

Thanks for the clarification
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC v5 00/38] powerpc: Memory Protection Keys Ram Pai <linuxram@us.ibm.com> - 2017-07-05 23:40 +0200
  Re: [RFC v5 00/38] powerpc: Memory Protection Keys Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-07-10 07:50 +0200
    Re: [RFC v5 00/38] powerpc: Memory Protection Keys Ram Pai <linuxram@us.ibm.com> - 2017-07-10 08:10 +0200
      Re: [RFC v5 00/38] powerpc: Memory Protection Keys Ram Pai <linuxram@us.ibm.com> - 2017-07-10 19:20 +0200
  Re: [RFC v5 00/38] powerpc: Memory Protection Keys Michal Hocko <mhocko@kernel.org> - 2017-07-11 17:00 +0200
    Re: [RFC v5 00/38] powerpc: Memory Protection Keys Ram Pai <linuxram@us.ibm.com> - 2017-07-11 21:40 +0200
      Re: [RFC v5 00/38] powerpc: Memory Protection Keys Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-07-12 00:10 +0200
      Re: [RFC v5 00/38] powerpc: Memory Protection Keys Michal Hocko <mhocko@kernel.org> - 2017-07-12 09:30 +0200
        Re: [RFC v5 00/38] powerpc: Memory Protection Keys Michal Hocko <mhocko@kernel.org> - 2017-07-12 09:50 +0200
        Re: [RFC v5 00/38] powerpc: Memory Protection Keys Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-07-13 01:00 +0200
          Re: [RFC v5 00/38] powerpc: Memory Protection Keys Michal Hocko <mhocko@kernel.org> - 2017-07-13 08:30 +0200
  Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory  protection keys Dave Hansen <dave.hansen@intel.com> - 2017-07-11 19:40 +0200
    Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory  protection keys Ram Pai <linuxram@us.ibm.com> - 2017-07-13 00:00 +0200

csiph-web