On Mon, Dec 11, 2017 at 5:39 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Andy Lutomirski <l...@kernel.org> wrote: > >> The kernel is very erratic as to which pagetables have _PAGE_USER >> set. The vsyscall page gets lucky: it seems that all of the >> relevant pagetables are among the apparently arbitrary ones that set >> _PAGE_USER. Rather than relying on chance, just explicitly set >> _PAGE_USER. >> >> This will let us clean up pagetable setup to stop setting >> _PAGE_USER. The added code can also be reused by pagetable >> isolation to manage the _PAGE_USER bit in the usermode tables. >> >> Signed-off-by: Andy Lutomirski <l...@kernel.org> >> --- >> arch/x86/entry/vsyscall/vsyscall_64.c | 33 ++++++++++++++++++++++++++++++++- >> 1 file changed, 32 insertions(+), 1 deletion(-) > > Btw., would it make sense to clean up all this confusion? > > In particular a 'KERNEL' pre of post fix is ambiguous in this context I > think, and > the PAGE_KERNEL_ prefix is actively harmful I think and is at the root of the > confusion. > > So if renamed it and used this nomenclature consistently instead: > > PAGE_USER_ > PAGE_SYSTEM_
Like _PAGE_USER_VSYSCALL? Anyway, that's not the confusion I'm talking about. I'm talking about _KERNPG_TABLE vs _PAGE_TABLE. The latter should be called _USERPG_TABLE, and a whole bunch of its users should be switched to _KERNPG_TABLE. But, since PTI is intended for backporting, I think these types of big cleanups should wait. > > ... and got rid of PAGE_KERNEL uses in arch/x86/, then it would be obvious at > first glance what kind of mapping is established in a particular place - and > it > would stay so in the future as well. > > ( There's some interaction with generic MM code which needs the original > defines > like PAGE_KERNEL[_EXEC], but those generic masks could be defined as > aliases, to > keep this cleanup within x86 for now. ) > > Thanks, > > Ingo
