* Dave Hansen <dave@xxxxxxxx> wrote: > On 07/11/2016 12:35 AM, Ingo Molnar wrote: > > * Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > mprotect_pkey()'s effects are per MM, but the system calls related to managing the > > keys (alloc/free/get/set) are fundamentally per CPU. > > > > Here's an example of how this could matter to applications: > > > > - 'writer thread' gets a RW- key into index 1 to a specific data area > > - a pool of 'reader threads' may get the same pkey index 1 R-- to read the data > > area. > > > > Same page tables, same index, two protections and two purposes. > > > > With a global, per MM allocation of keys we'd have to use two indices: index 1 and 2. > > I'm not sure how this would work. A piece of data mapped at only one virtual > address can have only one key associated with it. Yeah, indeed, got myself confused there - but the actual protection bits are per CPU (per task). > Remember, PKRU is just a *bitmap*. The only place keys are stored is in the > page tables. A pkey is an index *and* a protection mask. So by representing it as a bitmask we lose per thread information. This is what I meant by 'incomplete shadowing' - for example the debug code couldn't work: if we cleared a pkey in a task we wouldn't know what to restore it to with the current data structures, right? Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>