On Thu, Apr 26, 2018 at 10:57:31AM -0700, Dave Hansen wrote: > On 04/06/2018 06:09 PM, Ram Pai wrote: > > Well :). my point is add this code and delete the other > > code that you add later in that function. > > I don't think I'm understanding what your suggestion was. I looked at > the code and I honestly do not think I can remove any of it. > > For the plain (non-explicit pkey_mprotect()) case, there are exactly > four paths through __arch_override_mprotect_pkey(), resulting in three > different results. > > 1. New prot==PROT_EXEC, no pkey-exec support -> do not override > 2. New prot!=PROT_EXEC, old VMA not PROT_EXEC-> do not override > 3. New prot==PROT_EXEC, w/ pkey-exec support -> override to exec pkey > 4. New prot!=PROT_EXEC, old VMA is PROT_EXEC -> override to default > > I don't see any redundancy there, or any code that we can eliminate or > simplify. It was simpler before, but that's what where bug was. Your code is fine. But than the following code accomplishes the same outcome; arguably with a one line change. Its not a big deal. Just trying to clarify my comment. int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot, int pkey) { /* * Is this an mprotect_pkey() call? If so, never * override the value that came from the user. */ if (pkey != -1) return pkey; /* * Look for a protection-key-drive execute-only mapping * which is now being given permissions that are not * execute-only. Move it back to the default pkey. */ if (vma_is_pkey_exec_only(vma) && (prot != PROT_EXEC)) <-------- return ARCH_DEFAULT_PKEY; /* * The mapping is execute-only. Go try to get the * execute-only protection key. If we fail to do that, * fall through as if we do not have execute-only * support. */ if (prot == PROT_EXEC) { pkey = execute_only_pkey(vma->vm_mm); if (pkey > 0) return pkey; } /* * This is a vanilla, non-pkey mprotect (or we failed to * setup execute-only), inherit the pkey from the VMA we * are working on. */ return vma_pkey(vma); } -- Ram Pai