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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
