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

Groups > linux.kernel > #1668160 > unrolled thread

[RFC v2 00/12] powerpc: Memory Protection Keys

Started byRam Pai <linuxram@us.ibm.com>
First post2017-06-17 06:00 +0200
Last post2017-06-21 02:20 +0200
Articles 10 on this page of 50 — 6 participants

Back to article view | Back to linux.kernel

Contents

  [RFC v2 00/12] powerpc: Memory Protection Keys Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
    [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 09:00 +0200
        Re: [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 02:00 +0200
          Re: [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-21 05:20 +0200
            Re: [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 08:20 +0200
    [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI  exception Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 10:20 +0200
        Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI  exception Ram Pai <linuxram@us.ibm.com> - 2017-06-21 01:30 +0200
      Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-06-21 09:30 +0200
        Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI  exception Ram Pai <linuxram@us.ibm.com> - 2017-06-21 11:20 +0200
    [RFC v2 04/12] powerpc: store and restore the pkey state across context switches. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
    [RFC v2 05/12] powerpc: Implementation for sys_mprotect_pkey() system call. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 05/12] powerpc: Implementation for sys_mprotect_pkey() system call. "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-06-21 09:20 +0200
    [RFC v2 11/12]Documentation: Documentation updates. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 11/12]Documentation: Documentation updates. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 08:20 +0200
        Re: [RFC v2 11/12]Documentation: Documentation updates. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 02:10 +0200
    [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 12:30 +0200
        Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 01:30 +0200
          Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-21 07:40 +0200
            Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 08:40 +0200
      Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages. "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-06-21 08:50 +0200
        Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 11:40 +0200
      Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-22 11:10 +0200
        Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-22 18:30 +0200
    [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused the exception. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused the exception. Michael Ellerman <mpe@ellerman.id.au> - 2017-06-19 13:10 +0200
        Re: [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused  the exception. Ram Pai <linuxram@us.ibm.com> - 2017-06-19 20:00 +0200
          Re: [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused  the exception. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 08:50 +0200
            Re: [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused  the exception. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 02:00 +0200
        Re: [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused  the exception. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 02:00 +0200
    [RFC v2 03/12] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 03/12] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call. Michael Ellerman <mpe@ellerman.id.au> - 2017-06-19 14:20 +0200
        Re: [RFC v2 03/12] powerpc: Implement sys_pkey_alloc and  sys_pkey_free system call. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 00:50 +0200
    [RFC v2 06/12] powerpc: Program HPTE key protection bits. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 06/12] powerpc: Program HPTE key protection bits. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 10:30 +0200
        Re: [RFC v2 06/12] powerpc: Program HPTE key protection bits. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 01:30 +0200
    [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-17 06:00 +0200
      Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed  hpte pages. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 13:00 +0200
        Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 01:30 +0200
      Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages. "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-06-21 09:00 +0200
        Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed  hpte pages. Ram Pai <linuxram@us.ibm.com> - 2017-06-21 22:20 +0200
      Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages. "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-06-21 09:00 +0200
    Re: [RFC v2 12/12]selftest: Updated protection key selftest Michael Ellerman <mpe@ellerman.id.au> - 2017-06-19 13:10 +0200
    Re: [RFC v2 00/12] powerpc: Memory Protection Keys Balbir Singh <bsingharora@gmail.com> - 2017-06-20 07:20 +0200
      Re: [RFC v2 00/12] powerpc: Memory Protection Keys Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 08:10 +0200
      Re: [RFC v2 00/12] powerpc: Memory Protection Keys Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-06-20 12:00 +0200
    Re: [RFC v2 12/12]selftest: Updated protection key selftest Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-20 08:30 +0200
      Re: [RFC v2 12/12]selftest: Updated protection key selftest Ram Pai <linuxram@us.ibm.com> - 2017-06-21 02:20 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1671236 — Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.

FromRam Pai <linuxram@us.ibm.com>
Date2017-06-21 01:30 +0200
SubjectRe: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.
Message-ID<tUAKS-6CT-21@gated-at.bofh.it>
In reply to#1670665
On Tue, Jun 20, 2017 at 04:21:45PM +0530, Anshuman Khandual wrote:
> On 06/17/2017 09:22 AM, Ram Pai wrote:
> > Rearrange 64K PTE bits to  free  up  bits 3, 4, 5  and  6
> > in the 64K backed hpte pages. This along with the earlier
> > patch will entirely free up the four bits from 64K PTE.
> > 
> > This patch does the following change to 64K PTE that is
> > backed by 64K hpte.
> > 
> > H_PAGE_F_SECOND which occupied bit 4 moves to the second part
> >         of the pte.
> > H_PAGE_F_GIX which  occupied bit 5, 6 and 7 also moves to the
> >         second part of the pte.
> > 
> > since bit 7 is now freed up, we move H_PAGE_BUSY from bit 9
> > to bit 7. Trying to minimize gaps so that contiguous bits
> > can be allocated if needed in the future.
> > 
> > The second part of the PTE will hold
> > (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63.
> 
> I still dont understand how we freed up the 5th bit which is
> used in the 5th patch. Was that bit never used for any thing
> on 64K page size (64K and 4K mappings) ?

yes. it was not used. So I gladly used it :-)


RP

[toc] | [prev] | [next] | [standalone]

#1671405 — Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.

From"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Date2017-06-21 09:00 +0200
SubjectRe: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.
Message-ID<tUHMl-2Cu-1@gated-at.bofh.it>
In reply to#1668170
Ram Pai <linuxram@us.ibm.com> writes:

....

> diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
> index a84bb44..239ca86 100644
> --- a/arch/powerpc/mm/hugetlbpage-hash64.c
> +++ b/arch/powerpc/mm/hugetlbpage-hash64.c
> @@ -22,6 +22,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  		     pte_t *ptep, unsigned long trap, unsigned long flags,
>  		     int ssize, unsigned int shift, unsigned int mmu_psize)
>  {
> +	real_pte_t rpte;
>  	unsigned long vpn;
>  	unsigned long old_pte, new_pte;
>  	unsigned long rflags, pa, sz;
> @@ -61,6 +62,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  	} while(!pte_xchg(ptep, __pte(old_pte), __pte(new_pte)));
>
>  	rflags = htab_convert_pte_flags(new_pte);
> +	rpte = __real_pte(__pte(old_pte), ptep);
>
>  	sz = ((1UL) << shift);
>  	if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> @@ -71,15 +73,10 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  	/* Check if pte already has an hpte (case 2) */
>  	if (unlikely(old_pte & H_PAGE_HASHPTE)) {
>  		/* There MIGHT be an HPTE for this pte */
> -		unsigned long hash, slot;
> +		unsigned long gslot;
>
> -		hash = hpt_hash(vpn, shift, ssize);
> -		if (old_pte & H_PAGE_F_SECOND)
> -			hash = ~hash;
> -		slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
> -		slot += (old_pte & H_PAGE_F_GIX) >> H_PAGE_F_GIX_SHIFT;
> -
> -		if (mmu_hash_ops.hpte_updatepp(slot, rflags, vpn, mmu_psize,
> +		gslot = get_hidx_gslot(vpn, shift, ssize, rpte, 0);
> +		if (mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn, mmu_psize,
>  					       mmu_psize, ssize, flags) == -1)
>  			old_pte &= ~_PAGE_HPTEFLAGS;
>  	}
> @@ -106,8 +103,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  			return -1;
>  		}
>
> -		new_pte |= (slot << H_PAGE_F_GIX_SHIFT) &
> -			(H_PAGE_F_SECOND | H_PAGE_F_GIX);
> +		new_pte |= set_hidx_slot(ptep, rpte, 0, slot);

We don't really need rpte here. We are just need to track one entry
here. May be it becomes simpler if use different helpers for 4k hpte and
others ?

-aneesh

[toc] | [prev] | [next] | [standalone]

#1672003 — Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.

FromRam Pai <linuxram@us.ibm.com>
Date2017-06-21 22:20 +0200
SubjectRe: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.
Message-ID<tUUgx-2Hl-9@gated-at.bofh.it>
In reply to#1671405
On Wed, Jun 21, 2017 at 12:24:34PM +0530, Aneesh Kumar K.V wrote:
> Ram Pai <linuxram@us.ibm.com> writes:
> 
> ....
> 
> > diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
> > index a84bb44..239ca86 100644
> > --- a/arch/powerpc/mm/hugetlbpage-hash64.c
> > +++ b/arch/powerpc/mm/hugetlbpage-hash64.c
> > @@ -22,6 +22,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> >  		     pte_t *ptep, unsigned long trap, unsigned long flags,
> >  		     int ssize, unsigned int shift, unsigned int mmu_psize)
> >  {
> > +	real_pte_t rpte;
> >  	unsigned long vpn;
> >  	unsigned long old_pte, new_pte;
> >  	unsigned long rflags, pa, sz;
> > @@ -61,6 +62,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> >  	} while(!pte_xchg(ptep, __pte(old_pte), __pte(new_pte)));
> >
> >  	rflags = htab_convert_pte_flags(new_pte);
> > +	rpte = __real_pte(__pte(old_pte), ptep);
> >
> >  	sz = ((1UL) << shift);
> >  	if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> > @@ -71,15 +73,10 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> >  	/* Check if pte already has an hpte (case 2) */
> >  	if (unlikely(old_pte & H_PAGE_HASHPTE)) {
> >  		/* There MIGHT be an HPTE for this pte */
> > -		unsigned long hash, slot;
> > +		unsigned long gslot;
> >
> > -		hash = hpt_hash(vpn, shift, ssize);
> > -		if (old_pte & H_PAGE_F_SECOND)
> > -			hash = ~hash;
> > -		slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
> > -		slot += (old_pte & H_PAGE_F_GIX) >> H_PAGE_F_GIX_SHIFT;
> > -
> > -		if (mmu_hash_ops.hpte_updatepp(slot, rflags, vpn, mmu_psize,
> > +		gslot = get_hidx_gslot(vpn, shift, ssize, rpte, 0);
> > +		if (mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn, mmu_psize,
> >  					       mmu_psize, ssize, flags) == -1)
> >  			old_pte &= ~_PAGE_HPTEFLAGS;
> >  	}
> > @@ -106,8 +103,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> >  			return -1;
> >  		}
> >
> > -		new_pte |= (slot << H_PAGE_F_GIX_SHIFT) &
> > -			(H_PAGE_F_SECOND | H_PAGE_F_GIX);
> > +		new_pte |= set_hidx_slot(ptep, rpte, 0, slot);
> 
> We don't really need rpte here. We are just need to track one entry
> here. May be it becomes simpler if use different helpers for 4k hpte and
> others ?

actually we need rpte here. the hidx for these 64K-hpte backed PTEs are
now stored in the second half of the pte. 
I have abstracted the helpers, so that the caller need not
know the location of the hidx. It comes in really handy.

RP

[toc] | [prev] | [next] | [standalone]

#1671407 — Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.

From"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Date2017-06-21 09:00 +0200
SubjectRe: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.
Message-ID<tUHMm-2Cu-11@gated-at.bofh.it>
In reply to#1668170
Ram Pai <linuxram@us.ibm.com> writes:

> Rearrange 64K PTE bits to  free  up  bits 3, 4, 5  and  6
> in the 64K backed hpte pages. This along with the earlier
> patch will entirely free up the four bits from 64K PTE.
>
> This patch does the following change to 64K PTE that is
> backed by 64K hpte.
>
> H_PAGE_F_SECOND which occupied bit 4 moves to the second part
>         of the pte.
> H_PAGE_F_GIX which  occupied bit 5, 6 and 7 also moves to the
>         second part of the pte.
>
> since bit 7 is now freed up, we move H_PAGE_BUSY from bit 9
> to bit 7. Trying to minimize gaps so that contiguous bits
> can be allocated if needed in the future.
>
> The second part of the PTE will hold
> (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63.


This patch will be really simple, if you don't use the get_hidx_gslot() helper
>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
>  arch/powerpc/include/asm/book3s/64/hash-64k.h | 26 ++++++++------------------
>  arch/powerpc/mm/hash64_64k.c                  | 16 +++++++---------
>  arch/powerpc/mm/hugetlbpage-hash64.c          | 16 ++++++----------
>  3 files changed, 21 insertions(+), 37 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> index 0eb3c89..2fa5c60 100644
> --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> @@ -12,12 +12,8 @@
>   */
>  #define H_PAGE_COMBO   _RPAGE_RPN0 /* this is a combo 4k page */
>  #define H_PAGE_4K_PFN  _RPAGE_RPN1 /* PFN is for a single 4k page */
> -#define H_PAGE_F_SECOND	_RPAGE_RSV2	/* HPTE is in 2ndary HPTEG */
> -#define H_PAGE_F_GIX	(_RPAGE_RSV3 | _RPAGE_RSV4 | _RPAGE_RPN44)
> -#define H_PAGE_F_GIX_SHIFT	56
>
> -
> -#define H_PAGE_BUSY	_RPAGE_RPN42     /* software: PTE & hash are busy */
> +#define H_PAGE_BUSY	_RPAGE_RPN44     /* software: PTE & hash are busy */
>  #define H_PAGE_HASHPTE	_RPAGE_RPN43    /* PTE has associated HPTE */
>
>  /*
> @@ -56,24 +52,18 @@ static inline real_pte_t __real_pte(pte_t pte, pte_t *ptep)
>  	unsigned long *hidxp;
>
>  	rpte.pte = pte;
> -	rpte.hidx = 0;
> -	if (pte_val(pte) & H_PAGE_COMBO) {
> -		/*
> -		 * Make sure we order the hidx load against the H_PAGE_COMBO
> -		 * check. The store side ordering is done in __hash_page_4K
> -		 */
> -		smp_rmb();
> -		hidxp = (unsigned long *)(ptep + PTRS_PER_PTE);
> -		rpte.hidx = *hidxp;
> -	}
> +	/*
> +	 * The store side ordering is done in __hash_page_4K
> +	 */


This is not just __hash_page_4k related now and you need to explain the
stoer side ordering more. Are we doing this correctly now ?

> +	smp_rmb();
> +	hidxp = (unsigned long *)(ptep + PTRS_PER_PTE);
> +	rpte.hidx = *hidxp;
>  	return rpte;
>  }
>
>  static inline unsigned long __rpte_to_hidx(real_pte_t rpte, unsigned long index)
>  {
> -	if ((pte_val(rpte.pte) & H_PAGE_COMBO))
> -		return (rpte.hidx >> (index<<2)) & 0xf;
> -	return (pte_val(rpte.pte) >> H_PAGE_F_GIX_SHIFT) & 0xf;
> +	return ((rpte.hidx >> (index<<2)) & 0xfUL);
>  }
>
>  static inline unsigned long set_hidx_slot(pte_t *ptep, real_pte_t rpte,
> diff --git a/arch/powerpc/mm/hash64_64k.c b/arch/powerpc/mm/hash64_64k.c
> index 3702a3c..1c25ec2 100644
> --- a/arch/powerpc/mm/hash64_64k.c
> +++ b/arch/powerpc/mm/hash64_64k.c
> @@ -211,6 +211,7 @@ int __hash_page_64K(unsigned long ea, unsigned long access,
>  		    unsigned long vsid, pte_t *ptep, unsigned long trap,
>  		    unsigned long flags, int ssize)
>  {
> +	real_pte_t rpte;
>  	unsigned long hpte_group;
>  	unsigned long rflags, pa;
>  	unsigned long old_pte, new_pte;
> @@ -247,6 +248,7 @@ int __hash_page_64K(unsigned long ea, unsigned long access,
>  	} while (!pte_xchg(ptep, __pte(old_pte), __pte(new_pte)));
>
>  	rflags = htab_convert_pte_flags(new_pte);
> +	rpte = __real_pte(__pte(old_pte), ptep);
>
>  	if (cpu_has_feature(CPU_FTR_NOEXECUTE) &&
>  	    !cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> @@ -254,16 +256,13 @@ int __hash_page_64K(unsigned long ea, unsigned long access,
>
>  	vpn  = hpt_vpn(ea, vsid, ssize);
>  	if (unlikely(old_pte & H_PAGE_HASHPTE)) {
> +		unsigned long gslot;
> +
>  		/*
>  		 * There MIGHT be an HPTE for this pte
>  		 */
> -		hash = hpt_hash(vpn, shift, ssize);
> -		if (old_pte & H_PAGE_F_SECOND)
> -			hash = ~hash;
> -		slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
> -		slot += (old_pte & H_PAGE_F_GIX) >> H_PAGE_F_GIX_SHIFT;
> -
> -		if (mmu_hash_ops.hpte_updatepp(slot, rflags, vpn, MMU_PAGE_64K,
> +		gslot = get_hidx_gslot(vpn, shift, ssize, rpte, 0);
> +		if (mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn, MMU_PAGE_64K,
>  					       MMU_PAGE_64K, ssize,
>  					       flags) == -1)
>  			old_pte &= ~_PAGE_HPTEFLAGS;
> @@ -313,8 +312,7 @@ int __hash_page_64K(unsigned long ea, unsigned long access,
>  			return -1;
>  		}
>
> -		new_pte |= (slot << H_PAGE_F_GIX_SHIFT) &
> -				(H_PAGE_F_SECOND | H_PAGE_F_GIX);
> +		set_hidx_slot(ptep, rpte, 0, slot);
>  		new_pte = (new_pte & ~_PAGE_HPTEFLAGS) | H_PAGE_HASHPTE;
>  	}
>  	*ptep = __pte(new_pte & ~H_PAGE_BUSY);
> diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
> index a84bb44..239ca86 100644
> --- a/arch/powerpc/mm/hugetlbpage-hash64.c
> +++ b/arch/powerpc/mm/hugetlbpage-hash64.c
> @@ -22,6 +22,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  		     pte_t *ptep, unsigned long trap, unsigned long flags,
>  		     int ssize, unsigned int shift, unsigned int mmu_psize)
>  {
> +	real_pte_t rpte;
>  	unsigned long vpn;
>  	unsigned long old_pte, new_pte;
>  	unsigned long rflags, pa, sz;
> @@ -61,6 +62,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  	} while(!pte_xchg(ptep, __pte(old_pte), __pte(new_pte)));
>
>  	rflags = htab_convert_pte_flags(new_pte);
> +	rpte = __real_pte(__pte(old_pte), ptep);
>
>  	sz = ((1UL) << shift);
>  	if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> @@ -71,15 +73,10 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  	/* Check if pte already has an hpte (case 2) */
>  	if (unlikely(old_pte & H_PAGE_HASHPTE)) {
>  		/* There MIGHT be an HPTE for this pte */
> -		unsigned long hash, slot;
> +		unsigned long gslot;
>
> -		hash = hpt_hash(vpn, shift, ssize);
> -		if (old_pte & H_PAGE_F_SECOND)
> -			hash = ~hash;
> -		slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
> -		slot += (old_pte & H_PAGE_F_GIX) >> H_PAGE_F_GIX_SHIFT;
> -
> -		if (mmu_hash_ops.hpte_updatepp(slot, rflags, vpn, mmu_psize,
> +		gslot = get_hidx_gslot(vpn, shift, ssize, rpte, 0);
> +		if (mmu_hash_ops.hpte_updatepp(gslot, rflags, vpn, mmu_psize,
>  					       mmu_psize, ssize, flags) == -1)
>  			old_pte &= ~_PAGE_HPTEFLAGS;
>  	}
> @@ -106,8 +103,7 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  			return -1;
>  		}
>
> -		new_pte |= (slot << H_PAGE_F_GIX_SHIFT) &
> -			(H_PAGE_F_SECOND | H_PAGE_F_GIX);
> +		new_pte |= set_hidx_slot(ptep, rpte, 0, slot);
>  	}
>
>  	/*
> -- 
> 1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1669011 — Re: [RFC v2 12/12]selftest: Updated protection key selftest

FromMichael Ellerman <mpe@ellerman.id.au>
Date2017-06-19 13:10 +0200
SubjectRe: [RFC v2 12/12]selftest: Updated protection key selftest
Message-ID<tU2Jc-1RM-31@gated-at.bofh.it>
In reply to#1668160
Ram Pai <linuxram@us.ibm.com> writes:

> Added test support for PowerPC implementation off protection keys.
>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
>  tools/testing/selftests/vm/Makefile           |    1 +
>  tools/testing/selftests/vm/pkey-helpers.h     |  365 +++++++
>  tools/testing/selftests/vm/protection_keys.c  | 1451 +++++++++++++++++++++++++
>  tools/testing/selftests/x86/Makefile          |    2 +-
>  tools/testing/selftests/x86/pkey-helpers.h    |  219 ----
>  tools/testing/selftests/x86/protection_keys.c | 1395 ------------------------

Please split the move and the addition of the powerpc code into two
separate patches (move first). That way we can actually see what you're
doing to add powerpc support.

cheers

[toc] | [prev] | [next] | [standalone]

#1670276

FromBalbir Singh <bsingharora@gmail.com>
Date2017-06-20 07:20 +0200
Message-ID<tUjK1-4mm-5@gated-at.bofh.it>
In reply to#1668160
On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.

I presume by itself you mean protection between threads?

> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  a  address  range  within    its   address   space.

OK, so this is per VMA?

>  The process  than  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel.

This bit is not clear, how can the key be set without
involving the kernel? I presume you mean the key is set
in the PTE's and the access protection values can be
set without involving the kernel?

 Any  code that  violates   the  permissions
>  off the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64.
> It is enabled on HPTE 64K-page platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
> 	This patch series has passed all the protection key
> 	tests available in  the selftests directory.
> 	The tests are updated to work on both x86 and powerpc.

Balbir

[toc] | [prev] | [next] | [standalone]

#1670312

FromAnshuman Khandual <khandual@linux.vnet.ibm.com>
Date2017-06-20 08:10 +0200
Message-ID<tUkwp-4RO-9@gated-at.bofh.it>
In reply to#1670276
On 06/20/2017 10:40 AM, Balbir Singh wrote:
> On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
>> Memory protection keys enable applications to protect its
>> address space from inadvertent access or corruption from
>> itself.
> 
> I presume by itself you mean protection between threads?

Between threads due to race conditions or from the same thread
because of programming error.

> 
>>
>> The overall idea:
>>
>>  A process allocates a   key  and associates it with
>>  a  address  range  within    its   address   space.
> 
> OK, so this is per VMA?

Yeah but the same key can be given to multiple VMAs. Any
change will effect every VMA who got tagged by it.

> 
>>  The process  than  can  dynamically  set read/write 
>>  permissions on  the   key   without  involving  the 
>>  kernel.
> 
> This bit is not clear, how can the key be set without
> involving the kernel? I presume you mean the key is set

With pkey_mprotect() system call, all the effected PTEs get
tagged for once. Switching the permission happens just by
writing into the register on the fly.

> in the PTE's and the access protection values can be
> set without involving the kernel?

PTE setting happens once, access protection values can be
changed on the fly through register.

[toc] | [prev] | [next] | [standalone]

#1670610

FromBenjamin Herrenschmidt <benh@kernel.crashing.org>
Date2017-06-20 12:00 +0200
Message-ID<tUo70-6Xh-31@gated-at.bofh.it>
In reply to#1670276
On Tue, 2017-06-20 at 15:10 +1000, Balbir Singh wrote:
> On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> > Memory protection keys enable applications to protect its
> > address space from inadvertent access or corruption from
> > itself.
> 
> I presume by itself you mean protection between threads?

Not necessarily. You could have for example a JIT that
when it runs the JITed code, only "opens" the keys for
the VM itself, preventing the JITed code from "leaking out"

There are plenty of other usages...
> 
> > The overall idea:
> > 
> >  A process allocates a   key  and associates it with
> >  a  address  range  within    its   address   space.
> 
> OK, so this is per VMA?
> 
> >  The process  than  can  dynamically  set read/write 
> >  permissions on  the   key   without  involving  the 
> >  kernel.
> 
> This bit is not clear, how can the key be set without
> involving the kernel? I presume you mean the key is set
> in the PTE's and the access protection values can be
> set without involving the kernel?
> 
>  Any  code that  violates   the  permissions
> >  off the address space; as defined by its associated
> >  key, will receive a segmentation fault.
> > 
> > This patch series enables the feature on PPC64.
> > It is enabled on HPTE 64K-page platform.
> > 
> > ISA3.0 section 5.7.13 describes the detailed specifications.
> > 
> > 
> > Testing:
> > 	This patch series has passed all the protection key
> > 	tests available in  the selftests directory.
> > 	The tests are updated to work on both x86 and powerpc.
> 
> Balbir

[toc] | [prev] | [next] | [standalone]

#1670321 — Re: [RFC v2 12/12]selftest: Updated protection key selftest

FromAnshuman Khandual <khandual@linux.vnet.ibm.com>
Date2017-06-20 08:30 +0200
SubjectRe: [RFC v2 12/12]selftest: Updated protection key selftest
Message-ID<tUkPL-4Yr-3@gated-at.bofh.it>
In reply to#1668160
On 06/17/2017 09:22 AM, Ram Pai wrote:
> Added test support for PowerPC implementation off protection keys.
> 
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>

First of all, there are a lot of instances where we use *pkru*
named functions on power even the real implementations have
taken care of doing appropriate things. That looks pretty
hacky. We need to change them to generic names first before
adding both x86 and powerpc procedures inside it.

[toc] | [prev] | [next] | [standalone]

#1671257 — Re: [RFC v2 12/12]selftest: Updated protection key selftest

FromRam Pai <linuxram@us.ibm.com>
Date2017-06-21 02:20 +0200
SubjectRe: [RFC v2 12/12]selftest: Updated protection key selftest
Message-ID<tUBxg-7al-7@gated-at.bofh.it>
In reply to#1670321
On Tue, Jun 20, 2017 at 11:56:04AM +0530, Anshuman Khandual wrote:
> On 06/17/2017 09:22 AM, Ram Pai wrote:
> > Added test support for PowerPC implementation off protection keys.
> > 
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> 
> First of all, there are a lot of instances where we use *pkru*
> named functions on power even the real implementations have
> taken care of doing appropriate things. That looks pretty
> hacky. We need to change them to generic names first before
> adding both x86 and powerpc procedures inside it.

I have abstracted out the arch-specific code. References to
pkru should now be constricted to x86 code only. 

The patch, i acknowledge, is not easily reviewable.
As Michael Ellermen mentioned I will  break them into two patches.
One moves the file and the second does the code changes. That way
it will be easy to review.

RP

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web