On Mon, Oct 23, 2017 at 03:13:33PM +0530, Aneesh Kumar K.V wrote: > Ram Pai <linux...@us.ibm.com> writes: > > > cleanup the bits corresponding to a key in the AMR, and IAMR > > register, when the key is newly allocated/activated or is freed. > > We dont want some residual bits cause the hardware enforce > > unintended behavior when the key is activated or freed. > > > > Signed-off-by: Ram Pai <linux...@us.ibm.com> > > --- > > arch/powerpc/include/asm/pkeys.h | 12 ++++++++++++ > > 1 files changed, 12 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/include/asm/pkeys.h > > b/arch/powerpc/include/asm/pkeys.h > > index 5a83ed7..53bf13b 100644 > > --- a/arch/powerpc/include/asm/pkeys.h > > +++ b/arch/powerpc/include/asm/pkeys.h > > @@ -54,6 +54,8 @@ static inline bool mm_pkey_is_allocated(struct mm_struct > > *mm, int pkey) > > mm_set_pkey_is_allocated(mm, pkey)); > > } > > > > +extern void __arch_activate_pkey(int pkey); > > +extern void __arch_deactivate_pkey(int pkey); > > /* > > * Returns a positive, 5-bit key on success, or -1 on failure. > > */ > > @@ -80,6 +82,12 @@ static inline int mm_pkey_alloc(struct mm_struct *mm) > > > > ret = ffz((u32)mm_pkey_allocation_map(mm)); > > mm_set_pkey_allocated(mm, ret); > > + > > + /* > > + * enable the key in the hardware > > + */ > > + if (ret > 0) > > + __arch_activate_pkey(ret); > > return ret; > > } > > We are already arch specific because we are defining them in > arch/powerpc/include/asm/, then why __arch_activate_pkey() ?
almost all the memory-key internal functions are named with a two leading underbars. So just *loosely* following a convention within that file. The corresponding functions without the two underbars are the one exposed to the arch-neutral code. RP
