Messages in this thread | | | Date | Wed, 10 Jan 2018 08:15:10 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set |
| |
* Willy Tarreau <w@1wt.eu> wrote:
> When a syscall returns to userspace with pti_disable set, it means the > current mm is configured to disable page table isolation (PTI). In this > case, returns from kernel to user will not switch the CR3, leaving it > to the kernel one which already maps both user and kernel pages. This > avoids a TLB flush, and saves another one on next entry. > > Thanks to these changes, haproxy running under KVM went back from > 12700 conn/s (without PCID) or 19700 (with PCID) to 23100 once loaded > after calling prctl(), indicating that PTI has no measurable impact on > this workload. > > Signed-off-by: Willy Tarreau <w@1wt.eu> > Cc: Andy Lutomirski <luto@kernel.org> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Brian Gerst <brgerst@gmail.com> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Ingo Molnar <mingo@kernel.org> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Josh Poimboeuf <jpoimboe@redhat.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Kees Cook <keescook@chromium.org> > > v2: > - use pti_disable instead of task flag > --- > arch/x86/entry/calling.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index 2c0d3b5..5361a10 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -229,6 +229,11 @@ > > .macro SWITCH_TO_USER_CR3_NOSTACK scratch_reg:req scratch_reg2:req > ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI > + > + /* The "pti_disable" mm attribute is mirrored into this per-cpu var */ > + cmpb $0, PER_CPU_VAR(pti_disable) > + jne .Lend_\@
Could you please do this small change for future iterations:
s/per-cpu /per-CPU
... to make the spelling more consistent with the rest of the code base?
Thanks,
Ingo
| |