On Fri, Jun 14, 2019 at 05:32:31PM -0700, Alison Schofield wrote: > On Fri, Jun 14, 2019 at 01:51:37PM +0200, Peter Zijlstra wrote: > > On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote: > snip > > > /* > > > - * When pkey==NO_KEY we get legacy mprotect behavior here. > > > + * do_mprotect_ext() supports the legacy mprotect behavior plus extensions > > > + * for Protection Keys and Memory Encryption Keys. These extensions are > > > + * mutually exclusive and the behavior is: Well, here it states that the extentions are mutually exclusive. > > > + * (pkey==NO_KEY && keyid==NO_KEY) ==> legacy mprotect > > > + * (pkey is valid) ==> legacy mprotect plus Protection Key extensions > > > + * (keyid is valid) ==> legacy mprotect plus Encryption Key extensions > > > */ > > > static int do_mprotect_ext(unsigned long start, size_t len, > > > - unsigned long prot, int pkey) > > > + unsigned long prot, int pkey, int keyid) > > > { > > snip > > > > > I've missed the part where pkey && keyid results in a WARN or error or > > whatever. > > > I wasn't so sure about that since do_mprotect_ext() > is the call 'behind' the system calls. > > legacy mprotect always calls with: NO_KEY, NO_KEY > pkey_mprotect always calls with: pkey, NO_KEY > encrypt_mprotect always calls with NO_KEY, keyid > > Would a check on those arguments be debug only > to future proof this? But you then don't check that, anywhere, afaict.