On Sat, 17 Mar 2018, Ram Pai wrote: > On Fri, Mar 16, 2018 at 02:46:56PM -0700, Dave Hansen wrote: > > > > From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > > > > mm_pkey_is_allocated() treats pkey 0 as unallocated. That is > > inconsistent with the manpages, and also inconsistent with > > mm->context.pkey_allocation_map. Stop special casing it and only > > disallow values that are actually bad (< 0). > > > > The end-user visible effect of this is that you can now use > > mprotect_pkey() to set pkey=0. > > > > This is a bit nicer than what Ram proposed because it is simpler > > and removes special-casing for pkey 0. On the other hand, it does > > allow applciations to pkey_free() pkey-0, but that's just a silly > > thing to do, so we are not going to protect against it. > > So your proposal > (a) allocates pkey 0 implicitly, > (b) does not stop anyone from freeing pkey-0 > (c) and allows pkey-0 to be explicitly associated with any address range. > correct? > > My proposal > (a) allocates pkey 0 implicitly, > (b) stops anyone from freeing pkey-0 > (c) and allows pkey-0 to be explicitly associated with any address range. > > So the difference between the two proposals is just the freeing part i.e (b). > Did I get this right? Yes, and that's consistent with the other pkeys. > Its a philosophical debate; allow the user to shoot-in-the-feet or stop > from not doing so. There is no clear answer either way. I am fine either > way. The user can shoot himself already with the other pkeys, so adding another one does not matter and is again consistent. Thanks, tglx
