linux-kernel - Re: [patch V2 20/29] x86/dumpstack/64: Speedup in_exception

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1904052355570.1802@nanos.tec.linutronix.de>
Date:   Fri, 5 Apr 2019 23:56:29 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Andy Lutomirski <luto@...nel.org>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [patch V2 20/29] x86/dumpstack/64: Speedup
 in_exception_stack()

On Fri, 5 Apr 2019, Josh Poimboeuf wrote:
> On Fri, Apr 05, 2019 at 05:07:18PM +0200, Thomas Gleixner wrote:
> > 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@...utronix.de>
> > ---
> > V2: Simplify the macro maze
> 
> This is indeed a little better.  It's friday, have an ack.
> 
> Acked-by: Josh Poimboeuf <jpoimboe@...hat.com>
> 
> I don't like the clever ISTACK_* macro naming however...

Come on it's friday, time for a little bikeshedding :)