* Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> > --- a/include/uapi/asm-generic/siginfo.h~pkeys-09-siginfo 2015-09-16 10:48:15.584161859 -0700
> > +++ b/include/uapi/asm-generic/siginfo.h 2015-09-16 10:48:15.592162222 -0700
> > @@ -95,6 +95,13 @@ typedef struct siginfo {
> > void __user *_lower;
> > void __user *_upper;
> > } _addr_bnd;
> > + int _pkey; /* FIXME: protection key value??
> > + * Do we really need this in here?
> > + * userspace can get the PKRU value in
> > + * the signal handler, but they do not
> > + * easily have access to the PKEY value
> > + * from the PTE.
> > + */
> > } _sigfault;
>
> A couple of comments:
>
> 1)
>
> Please use our ABI types - this one should be 'u32' I think.
>
> We could use 'u8' as well here, and mark another 3 bytes next to it as reserved
> for future flags. Right now protection keys use 4 bits, but do you really think
> they'll ever grow beyond 8 bits? PTE bits are a scarce resource in general.
>
> 2)
>
> To answer your question in the comment: it looks useful to have some sort of
> 'extended page fault error code' information here, which shows why the page fault
> happened. With the regular error_code it's easy - with protection keys there's 16
> separate keys possible and user-space might not know the actual key value in the
> pte.
Btw., alternatively we could also say that user-space should know what protection
key it used when it created the mapping - there's no need to recover it for every
page fault.
OTOH, as long as we don't do a separate find_vma(), it looks cheap enough to look
up the pkey value of that address and give it to user-space in the signal frame.
Btw., how does pkey support interact with hugepages?
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>