* Ingo Molnar <mi...@kernel.org> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
