On Fri, Aug 11, 2017 at 04:34:19PM +1000, Michael Ellerman wrote: > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes: > > > Ram Pai <linux...@us.ibm.com> writes: > >> --- a/arch/powerpc/kernel/process.c > >> +++ b/arch/powerpc/kernel/process.c > >> @@ -42,6 +42,7 @@ > >> #include <linux/hw_breakpoint.h> > >> #include <linux/uaccess.h> > >> #include <linux/elf-randomize.h> > >> +#include <linux/pkeys.h> > >> > >> #include <asm/pgtable.h> > >> #include <asm/io.h> > >> @@ -1096,6 +1097,13 @@ static inline void save_sprs(struct thread_struct > >> *t) > >> t->tar = mfspr(SPRN_TAR); > >> } > >> #endif > >> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > >> + if (arch_pkeys_enabled()) { > >> + t->amr = mfspr(SPRN_AMR); > >> + t->iamr = mfspr(SPRN_IAMR); > >> + t->uamor = mfspr(SPRN_UAMOR); > >> + } > >> +#endif > >> } > > > > Is it worth having a flag in thread_struct saying whether it has every > > called pkey_alloc and only do the mfsprs if it did?
Yes. This will further optimize the code; a great thing! > > Yes, in fact there's a programming note in the UAMOR section of the arch > that says exactly that. > > On the write side you have to be a bit more careful. You have to make > sure you set the UAMOR to 0 when you're switching from a process that > has used keys to one that isn't. Currently we save and restore AMR/IAMR/UAMOR if the OS has enabled pkeys. This means the UAMOR will get restored to 0 if the application has not used any keys. But if we do optimize the code further; as suggested by Thiago, we will have to be careful with initializing UAMOR while switching back task that has not used the keys yet. RP > > cheers -- Ram Pai