All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	arnd@arndb.de, corbet@lwn.net, mhocko@kernel.org,
	dave.hansen@intel.com, mingo@redhat.com, paulus@samba.org,
	aneesh.kumar@linux.vnet.ibm.com, akpm@linux-foundation.org,
	khandual@linux.vnet.ibm.com
Subject: Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
Date: Mon, 31 Jul 2017 13:19:40 -0300	[thread overview]
Message-ID: <87efsw60kj.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170730005137.GK5664@ram.oc3035372033.ibm.com>


Ram Pai <linuxram@us.ibm.com> writes:

> On Fri, Jul 28, 2017 at 07:17:13PM -0300, Thiago Jung Bauermann wrote:
>> 
>> Ram Pai <linuxram@us.ibm.com> writes:
>> > --- a/arch/powerpc/mm/pkeys.c
>> > +++ b/arch/powerpc/mm/pkeys.c
>> > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
>> >  	init_iamr(pkey, new_iamr_bits);
>> >  	return 0;
>> >  }
>> > +
>> > +static inline bool pkey_allows_readwrite(int pkey)
>> > +{
>> > +	int pkey_shift = pkeyshift(pkey);
>> > +
>> > +	if (!(read_uamor() & (0x3UL << pkey_shift)))
>> > +		return true;
>> > +
>> > +	return !(read_amr() & ((AMR_RD_BIT|AMR_WR_BIT) << pkey_shift));
>> > +}
>> > +
>> > +int __execute_only_pkey(struct mm_struct *mm)
>> > +{
>> > +	bool need_to_set_mm_pkey = false;
>> > +	int execute_only_pkey = mm->context.execute_only_pkey;
>> > +	int ret;
>> > +
>> > +	/* Do we need to assign a pkey for mm's execute-only maps? */
>> > +	if (execute_only_pkey == -1) {
>> > +		/* Go allocate one to use, which might fail */
>> > +		execute_only_pkey = mm_pkey_alloc(mm);
>> > +		if (execute_only_pkey < 0)
>> > +			return -1;
>> > +		need_to_set_mm_pkey = true;
>> > +	}
>> > +
>> > +	/*
>> > +	 * We do not want to go through the relatively costly
>> > +	 * dance to set AMR if we do not need to.  Check it
>> > +	 * first and assume that if the execute-only pkey is
>> > +	 * readwrite-disabled than we do not have to set it
>> > +	 * ourselves.
>> > +	 */
>> > +	if (!need_to_set_mm_pkey &&
>> > +	    !pkey_allows_readwrite(execute_only_pkey))
> 		^^^^^
> 	Here uamor and amr is read once each.

You are right. What confused me was that the call to mm_pkey_alloc above
also reads uamor and amr (and also iamr, and writes to all of those) but
if that function is called, then need_to_set_mm_pkey is true and
pkey_allows_readwrite won't be called.

>> > +		return execute_only_pkey;
>> > +
>> > +	/*
>> > +	 * Set up AMR so that it denies access for everything
>> > +	 * other than execution.
>> > +	 */
>> > +	ret = __arch_set_user_pkey_access(current, execute_only_pkey,
>> > +			(PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE));
> 		^^^^^^^
> 		here amr and iamr are written once each if the
> 		the function returns successfully.

__arch_set_user_pkey_access also reads uamor for the second time in its
call to is_pkey_enabled, and reads amr for the second time as well in
its calls to init_amr. The first reads are in either
pkey_allows_readwrite or pkey_status_change (called from
__arch_activate_pkey).

If need_to_set_mm_pkey is true, then the iamr read in init_iamr is the
2nd one during __execute_only_pkey's execution. In this case the writes
to amr and iamr will be the 2nd ones as well. The first reads and writes
are in pkey_status_change.

>> > +	/*
>> > +	 * If the AMR-set operation failed somehow, just return
>> > +	 * 0 and effectively disable execute-only support.
>> > +	 */
>> > +	if (ret) {
>> > +		mm_set_pkey_free(mm, execute_only_pkey);
> 		^^^
> 		here only if __arch_set_user_pkey_access() fails
> 		amr and iamr and uamor will be written once each.

I assume the error case isn't perfomance sensitive and didn't account
for mm_set_pkey_free in my analysis.

>> > +		return -1;
>> > +	}
>> > +
>> > +	/* We got one, store it and use it from here on out */
>> > +	if (need_to_set_mm_pkey)
>> > +		mm->context.execute_only_pkey = execute_only_pkey;
>> > +	return execute_only_pkey;
>> > +}
>> 
>> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR
>> are read 3 times in total, and AMR is written twice. IAMR is read and
>> written twice. Since they are SPRs and access to them is slow (or isn't
>> it?), is it worth it to read them once in __execute_only_pkey and pass
>> down their values to the callees, and then write them once at the end of
>> the function?
>
> If my calculations are right: 
> 	uamor may be read once and may be written once.
> 	amr may be read once and is written once.
> 	iamr is written once.
> So not that bad, i think.

If I'm following the code correctly:
    if need_to_set_mm_pkey = true:
        uamor is read twice and written once.
        amr is read twice and written twice.
        iamr is read twice and written twice.
    if need_to_set_mm_pkey = false:
        uamor is read twice.
        amr is read once or twice (depending on the value of uamor) and written once.
        iamr is read once and written once.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	arnd@arndb.de, corbet@lwn.net, mhocko@kernel.org,
	dave.hansen@intel.com, mingo@redhat.com, paulus@samba.org,
	aneesh.kumar@linux.vnet.ibm.com, akpm@linux-foundation.org,
	khandual@linux.vnet.ibm.com
Subject: Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
Date: Mon, 31 Jul 2017 13:19:40 -0300	[thread overview]
Message-ID: <87efsw60kj.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170730005137.GK5664@ram.oc3035372033.ibm.com>


Ram Pai <linuxram@us.ibm.com> writes:

> On Fri, Jul 28, 2017 at 07:17:13PM -0300, Thiago Jung Bauermann wrote:
>> 
>> Ram Pai <linuxram@us.ibm.com> writes:
>> > --- a/arch/powerpc/mm/pkeys.c
>> > +++ b/arch/powerpc/mm/pkeys.c
>> > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
>> >  	init_iamr(pkey, new_iamr_bits);
>> >  	return 0;
>> >  }
>> > +
>> > +static inline bool pkey_allows_readwrite(int pkey)
>> > +{
>> > +	int pkey_shift = pkeyshift(pkey);
>> > +
>> > +	if (!(read_uamor() & (0x3UL << pkey_shift)))
>> > +		return true;
>> > +
>> > +	return !(read_amr() & ((AMR_RD_BIT|AMR_WR_BIT) << pkey_shift));
>> > +}
>> > +
>> > +int __execute_only_pkey(struct mm_struct *mm)
>> > +{
>> > +	bool need_to_set_mm_pkey = false;
>> > +	int execute_only_pkey = mm->context.execute_only_pkey;
>> > +	int ret;
>> > +
>> > +	/* Do we need to assign a pkey for mm's execute-only maps? */
>> > +	if (execute_only_pkey == -1) {
>> > +		/* Go allocate one to use, which might fail */
>> > +		execute_only_pkey = mm_pkey_alloc(mm);
>> > +		if (execute_only_pkey < 0)
>> > +			return -1;
>> > +		need_to_set_mm_pkey = true;
>> > +	}
>> > +
>> > +	/*
>> > +	 * We do not want to go through the relatively costly
>> > +	 * dance to set AMR if we do not need to.  Check it
>> > +	 * first and assume that if the execute-only pkey is
>> > +	 * readwrite-disabled than we do not have to set it
>> > +	 * ourselves.
>> > +	 */
>> > +	if (!need_to_set_mm_pkey &&
>> > +	    !pkey_allows_readwrite(execute_only_pkey))
> 		^^^^^
> 	Here uamor and amr is read once each.

You are right. What confused me was that the call to mm_pkey_alloc above
also reads uamor and amr (and also iamr, and writes to all of those) but
if that function is called, then need_to_set_mm_pkey is true and
pkey_allows_readwrite won't be called.

>> > +		return execute_only_pkey;
>> > +
>> > +	/*
>> > +	 * Set up AMR so that it denies access for everything
>> > +	 * other than execution.
>> > +	 */
>> > +	ret = __arch_set_user_pkey_access(current, execute_only_pkey,
>> > +			(PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE));
> 		^^^^^^^
> 		here amr and iamr are written once each if the
> 		the function returns successfully.

__arch_set_user_pkey_access also reads uamor for the second time in its
call to is_pkey_enabled, and reads amr for the second time as well in
its calls to init_amr. The first reads are in either
pkey_allows_readwrite or pkey_status_change (called from
__arch_activate_pkey).

If need_to_set_mm_pkey is true, then the iamr read in init_iamr is the
2nd one during __execute_only_pkey's execution. In this case the writes
to amr and iamr will be the 2nd ones as well. The first reads and writes
are in pkey_status_change.

>> > +	/*
>> > +	 * If the AMR-set operation failed somehow, just return
>> > +	 * 0 and effectively disable execute-only support.
>> > +	 */
>> > +	if (ret) {
>> > +		mm_set_pkey_free(mm, execute_only_pkey);
> 		^^^
> 		here only if __arch_set_user_pkey_access() fails
> 		amr and iamr and uamor will be written once each.

I assume the error case isn't perfomance sensitive and didn't account
for mm_set_pkey_free in my analysis.

>> > +		return -1;
>> > +	}
>> > +
>> > +	/* We got one, store it and use it from here on out */
>> > +	if (need_to_set_mm_pkey)
>> > +		mm->context.execute_only_pkey = execute_only_pkey;
>> > +	return execute_only_pkey;
>> > +}
>> 
>> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR
>> are read 3 times in total, and AMR is written twice. IAMR is read and
>> written twice. Since they are SPRs and access to them is slow (or isn't
>> it?), is it worth it to read them once in __execute_only_pkey and pass
>> down their values to the callees, and then write them once at the end of
>> the function?
>
> If my calculations are right: 
> 	uamor may be read once and may be written once.
> 	amr may be read once and is written once.
> 	iamr is written once.
> So not that bad, i think.

If I'm following the code correctly:
    if need_to_set_mm_pkey = true:
        uamor is read twice and written once.
        amr is read twice and written twice.
        iamr is read twice and written twice.
    if need_to_set_mm_pkey = false:
        uamor is read twice.
        amr is read once or twice (depending on the value of uamor) and written once.
        iamr is read once and written once.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-07-31 16:19 UTC|newest]

Thread overview: 230+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-16  3:56 [RFC v6 00/62] powerpc: Memory Protection Keys Ram Pai
2017-07-16  3:56 ` Ram Pai
2017-07-16  3:56 ` [RFC v6 01/62] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:51   ` Aneesh Kumar K.V
2017-07-20  5:51     ` Aneesh Kumar K.V
2017-07-20  5:51     ` Aneesh Kumar K.V
2017-07-20  5:51     ` Aneesh Kumar K.V
2017-07-20 22:03     ` Ram Pai
2017-07-20 22:03       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 02/62] powerpc: Free up four 64K PTE bits in 64K " Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:53   ` Aneesh Kumar K.V
2017-07-20  5:53     ` Aneesh Kumar K.V
2017-07-20  5:53     ` Aneesh Kumar K.V
2017-07-20  5:53     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 03/62] powerpc: introduce pte_set_hash_slot() helper Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:56   ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 04/62] powerpc: introduce pte_get_hash_gslot() helper Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:57   ` Aneesh Kumar K.V
2017-07-20  5:57     ` Aneesh Kumar K.V
2017-07-20  5:57     ` Aneesh Kumar K.V
2017-07-20  5:57     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 05/62] powerpc: capture the PTE format changes in the dump pte report Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:56   ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-20  5:56     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 06/62] powerpc: use helper functions in __hash_page_64K() for 64K PTE Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:58   ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 07/62] powerpc: use helper functions in __hash_page_huge() " Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  5:58   ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-20  5:58     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 08/62] powerpc: use helper functions in __hash_page_4K() " Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 09/62] powerpc: use helper functions in __hash_page_4K() for 4K PTE Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 10/62] powerpc: use helper functions in flush_hash_page() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 11/62] powerpc: initial pkey plumbing Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  6:04   ` Aneesh Kumar K.V
2017-07-20  6:04     ` Aneesh Kumar K.V
2017-07-20  6:04     ` Aneesh Kumar K.V
2017-07-20  6:04     ` Aneesh Kumar K.V
2017-07-20 22:11     ` Ram Pai
2017-07-20 22:11       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 12/62] mm: introduce an additional vma bit for powerpc pkey Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 13/62] powerpc: track allocation status of all pkeys Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-27 14:01   ` Thiago Jung Bauermann
2017-07-27 14:01     ` Thiago Jung Bauermann
2017-07-29 22:43     ` Ram Pai
2017-07-29 22:43       ` Ram Pai
2017-07-29 22:43       ` Ram Pai
2017-07-31 18:15   ` Thiago Jung Bauermann
2017-07-31 18:15     ` Thiago Jung Bauermann
2017-07-16  3:56 ` [RFC v6 14/62] powerpc: helper function to read,write AMR,IAMR,UAMOR registers Ram Pai
2017-07-16  3:56   ` [RFC v6 14/62] powerpc: helper function to read, write AMR, IAMR, UAMOR registers Ram Pai
2017-07-16  3:56   ` [RFC v6 14/62] powerpc: helper function to read,write AMR,IAMR,UAMOR registers Ram Pai
2017-07-16  3:56 ` [RFC v6 15/62] powerpc: helper functions to initialize AMR, IAMR and UMOR registers Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-27 20:40   ` Thiago Jung Bauermann
2017-07-27 20:40     ` Thiago Jung Bauermann
2017-07-30  0:38     ` Ram Pai
2017-07-30  0:38       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 16/62] powerpc: cleaup AMR,iAMR when a key is allocated or freed Ram Pai
2017-07-16  3:56   ` [RFC v6 16/62] powerpc: cleaup AMR, iAMR " Ram Pai
2017-07-16  3:56   ` [RFC v6 16/62] powerpc: cleaup AMR,iAMR " Ram Pai
2017-07-16  3:56 ` [RFC v6 17/62] powerpc: implementation for arch_set_user_pkey_access() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-27 14:15   ` Thiago Jung Bauermann
2017-07-27 14:15     ` Thiago Jung Bauermann
2017-07-29 22:59     ` Ram Pai
2017-07-29 22:59       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 18/62] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 19/62] powerpc: ability to create execute-disabled pkeys Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-27 14:54   ` Thiago Jung Bauermann
2017-07-27 14:54     ` Thiago Jung Bauermann
2017-07-27 15:34     ` Thiago Jung Bauermann
2017-07-27 15:34       ` Thiago Jung Bauermann
2017-07-29 23:24     ` Ram Pai
2017-07-29 23:24       ` Ram Pai
2017-07-31 12:59       ` Michael Ellerman
2017-07-31 12:59         ` Michael Ellerman
2017-07-16  3:56 ` [RFC v6 20/62] powerpc: store and restore the pkey state across context switches Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-27 17:32   ` Thiago Jung Bauermann
2017-07-27 17:32     ` Thiago Jung Bauermann
2017-07-29 23:31     ` Ram Pai
2017-07-29 23:31       ` Ram Pai
2017-07-31 13:00       ` Michael Ellerman
2017-07-31 13:00         ` Michael Ellerman
2017-07-16  3:56 ` [RFC v6 21/62] powerpc: introduce execute-only pkey Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-28 22:17   ` Thiago Jung Bauermann
2017-07-28 22:17     ` Thiago Jung Bauermann
2017-07-30  0:51     ` Ram Pai
2017-07-30  0:51       ` Ram Pai
2017-07-31 16:19       ` Thiago Jung Bauermann [this message]
2017-07-31 16:19         ` Thiago Jung Bauermann
2017-08-01  6:46     ` Michael Ellerman
2017-08-01  6:46       ` Michael Ellerman
2017-08-01 16:14       ` Thiago Jung Bauermann
2017-08-01 16:14         ` Thiago Jung Bauermann
2017-08-01 16:14         ` Thiago Jung Bauermann
2017-08-02  9:40         ` Michael Ellerman
2017-08-02  9:40           ` Michael Ellerman
     [not found]           ` <20170817233555.GC5427@ram.oc3035372033.ibm.com>
2017-08-17 23:42             ` Ram Pai
2017-08-17 23:42               ` Ram Pai
2017-07-16  3:56 ` [RFC v6 22/62] powerpc: ability to associate pkey to a vma Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 23/62] powerpc: implementation for arch_override_mprotect_pkey() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 24/62] powerpc: map vma key-protection bits to pte key bits Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 25/62] powerpc: sys_pkey_mprotect() system call Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 26/62] powerpc: Program HPTE key protection bits Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  6:28   ` Aneesh Kumar K.V
2017-07-20  6:28     ` Aneesh Kumar K.V
2017-07-20  6:28     ` Aneesh Kumar K.V
2017-07-20  6:28     ` Aneesh Kumar K.V
2017-07-16  3:56 ` [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-20  6:42   ` Aneesh Kumar K.V
2017-07-20  6:42     ` Aneesh Kumar K.V
2017-07-20  6:42     ` Aneesh Kumar K.V
2017-07-20  6:42     ` Aneesh Kumar K.V
2017-07-20 22:15     ` Ram Pai
2017-07-20 22:15       ` Ram Pai
2017-07-21  6:51       ` Aneesh Kumar K.V
2017-07-21  6:51         ` Aneesh Kumar K.V
2017-07-21 16:42         ` Ram Pai
2017-07-21 16:42           ` Ram Pai
2017-07-28 21:00   ` Thiago Jung Bauermann
2017-07-28 21:00     ` Thiago Jung Bauermann
2017-07-30  0:39     ` Ram Pai
2017-07-30  0:39       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 28/62] powerpc: check key protection for user page access Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 29/62] powerpc: Macro the mask used for checking DSI exception Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 30/62] powerpc: implementation for arch_vma_access_permitted() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 31/62] powerpc: Handle exceptions caused by pkey violation Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 32/62] powerpc: capture AMR register content on " Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 33/62] powerpc: introduce get_pte_pkey() helper Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 34/62] powerpc: capture the violated protection key on fault Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-08-19 19:09   ` Eric W. Biederman
2017-08-19 19:09     ` Eric W. Biederman
2017-08-22 18:06     ` Ram Pai
2017-08-22 18:06       ` Ram Pai
2017-07-16  3:56 ` [RFC v6 36/62] mm: introduce arch_pkeys_enabled() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 37/62] x86: implementation for arch_pkeys_enabled() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 38/62] powerpc: " Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 39/62] mm: display pkey in smaps if arch_pkeys_enabled() is true Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 40/62] x86: delete arch_show_smap() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 41/62] selftest/x86: Move protecton key selftest to arch neutral directory Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 42/62] selftest/vm: rename all references to pkru to a generic name Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 43/62] selftest/vm: move generic definitions to header file Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 44/62] selftest/vm: typecast the pkey register Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 45/62] selftest/vm: generics function to handle shadow key register Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 46/62] selftest/vm: fix the wrong assert in pkey_disable_set() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 47/62] selftest/vm: fixed bugs in pkey_disable_clear() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 48/62] selftest/vm: clear the bits in shadow reg when a pkey is freed Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 49/62] selftest/vm: fix alloc_random_pkey() to make it really random Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 50/62] selftest/vm: introduce two arch independent abstraction Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 51/62] selftest/vm: pkey register should match shadow pkey Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 52/62] selftest/vm: generic cleanup Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 53/62] selftest/vm: powerpc implementation for generic abstraction Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 54/62] selftest/vm: fix an assertion in test_pkey_alloc_exhaust() Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 55/62] selftest/vm: associate key on a mapped page and detect access violation Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 56/62] selftest/vm: detect no key violation on a freed key Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:56 ` [RFC v6 57/62] selftest/vm: associate key on a mapped page and detect write violation Ram Pai
2017-07-16  3:56   ` Ram Pai
2017-07-16  3:57 ` [RFC v6 58/62] selftest/vm: detect no write key-violation on a freed key Ram Pai
2017-07-16  3:57   ` Ram Pai
2017-07-16  3:57 ` [RFC v6 59/62] selftest/vm: detect write violation on a mapped access-denied-key page Ram Pai
2017-07-16  3:57   ` Ram Pai
2017-07-16  3:57 ` [RFC v6 60/62] selftest/vm: sub-page allocator Ram Pai
2017-07-16  3:57   ` Ram Pai
2017-07-16  3:57 ` [RFC v6 61/62] Documentation/x86: Move protecton key documentation to arch neutral directory Ram Pai
2017-07-16  3:57   ` Ram Pai
2017-07-16  3:57 ` [RFC v6 62/62] Documentation/vm: PowerPC specific updates to memory protection keys Ram Pai
2017-07-16  3:57   ` Ram Pai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efsw60kj.fsf@linux.vnet.ibm.com \
    --to=bauerman@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.