On Sun, Mar 18, 2018 at 10:30:48AM +0100, Thomas Gleixner wrote: > 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. > ok. Yes it makes pkey-0 even more consistent with the other keys, but not entirely consistent. pkey-0 still has the priviledge of being allocated by default. RP
