summaryrefslogtreecommitdiff
path: root/arch/x86/include/asm/processor.h
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2019-04-14 17:59:58 +0200
committerBorislav Petkov <bp@suse.de>2019-04-17 15:16:57 +0200
commitc450c8f532b63475b30e29bc600c25ab0a4ab282 (patch)
tree22f36425a4e720fca3216f6b2c129d3a078d5f1e /arch/x86/include/asm/processor.h
parent2a594d4ccf3f10f80b77d71bd3dad10813ac0137 (diff)
x86/dumpstack/64: Speedup in_exception_stack()
The current implementation of in_exception_stack() iterates over the exception stacks array. Most of the time this is an useless exercise, but even for the actual use cases (perf and ftrace) it takes at least 2 iterations to get to the NMI stack. As the exception stacks and the guard pages are page aligned the loop can be avoided completely. Add a initial check whether the stack pointer is inside the full exception stack area and leave early if not. Create a lookup table which describes the stack area. The table index is the page offset from the beginning of the exception stacks. So for any given stack pointer the page offset is computed and a lookup in the description table is performed. If it is inside a guard page, return. If not, use the descriptor to fill in the info structure. The table is filled at compile time and for the !KASAN case the interesting page descriptors exactly fit into a single cache line. Just the last guard page descriptor is in the next cacheline, but that should not be accessed in the regular case. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Sean Christopherson <sean.j.christopherson@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190414160145.543320386@linutronix.de
Diffstat (limited to 'arch/x86/include/asm/processor.h')
0 files changed, 0 insertions, 0 deletions