lkml.org 
[lkml]   [2015]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls
From
Date
On 09/04/2015 01:13 PM, Florian Weimer wrote:
...
>>>> >>> #define PROT_WRITE 0x2 /* page can be written */
>>>> >>> #define PROT_EXEC 0x4 /* page can be executed */
>>>> >>> #define PROT_SEM 0x8 /* page may be used for atomic ops */
>>>> >>> +#define PROT_PKEY0 0x10 /* protection key value (bit 0) */
>>>> >>> +#define PROT_PKEY1 0x20 /* protection key value (bit 1) */
>>>> >>> +#define PROT_PKEY2 0x40 /* protection key value (bit 2) */
>>>> >>> +#define PROT_PKEY3 0x80 /* protection key value (bit 3) */
>>> >>
>>> >> Thats leaking deep Intelisms into asm-generic which makes me very
>>> >> uncomfortable. Whether we need to reserve some bits for "arch specific"
>>> >> is one question, what we do with them ought not to be leaking out.
>>> >>
>>> >> To start with trying to port code people will want to do
>>> >>
>>> >> #define PROT_PKEY0 0
>>> >> #define PROT_PKEY1 0
>> >
>> > Yeah, I feel pretty uncomfortable with it as well. I really don't
>> > expect these to live like this in asm-generic when I submit this.
>> >
>> > Powerpc and ia64 have _something_ resembling protection keys, so the
>> > concept isn't entirely x86 or Intel-specific. My hope would be that we
>> > do this in a way that other architectures can use.
> It will also be very painful to add additional bits. We went through
> this with the CPU affinity mask, and it still hurts it. Please use a
> more sensible interface from the start. :)

Any suggestions?

Are you thinking that we want a completely separate syscall and
completely avoid using the PROT_* bits?


\
 
 \ /
  Last update: 2015-09-04 22:41    [W:0.061 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site