On 11/23/2017 01:42 PM, Vlastimil Babka wrote: >> It's supposed to set 0. >> >> -1 was, as far as I remember, an internal-to-the-kernel-only thing to >> tell us that a key came from *mprotect()* instead of pkey_mprotect(). > So, pkey_mprotect(..., 0) will set it to 0, regardless of PROT_EXEC. Although weird, the thought here was that pkey_mprotect() callers are new and should know about the interactions with PROT_EXEC. They can also *get* PROT_EXEC semantics if they want. The only wart here is if you do: mprotect(..., PROT_EXEC); // key 10 is now the PROT_EXEC key pkey_mprotect(..., PROT_EXEC, key=3); I'm not sure what this does. We should probably ensure that it returns an error. > pkey_mprotect(..., -1) or mprotect() will set it to 0-or-PROT_EXEC-pkey. > > Can't shake the feeling that it's somewhat weird, but I guess it's > flexible at least. So just has to be well documented. It *is* weird. But, layering on top of legacy APIs are often weird. I would have been open to other sane, but less weird ways to do it a year ago. :) -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
