linux-kernel - Re: [patch V4 part 1 07/36] locking/atomics: Flip fallbacks and instrumentation

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]

Date:   Thu, 7 May 2020 19:41:27 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Brian Gerst <brgerst@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Will Deacon <will@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [patch V4 part 1 07/36] locking/atomics: Flip fallbacks and
 instrumentation

On Tue, 05 May 2020 15:16:09 +0200
Thomas Gleixner <tglx@...utronix.de> wrote:

> Currently instrumentation of atomic primitives is done at the
> architecture level, while composites or fallbacks are provided at the
> generic level.
> 
> The result is that there are no uninstrumented variants of the
> fallbacks. Since there is now need of such (see the next patch),

Just a comment on the change log. Can we avoid saying "see the next patch"?
A few years from now, if we stumble on changes in this commit and need to
see that next patch, if something happened to lore, it may be difficult to
find what that next patch was. But saying that patch's subject, would be
just a simple search in the git history.

That said, looking at "the next patch" which is "x86/doublefault: Remove
memmove() call", does that patch really have a need for such?

-- Steve



> invert this ordering.
> 
> Doing this means moving the instrumentation into the generic code as
> well as having (for now) two variants of the fallbacks.
> 
> Notes:
> 
>  - the various *cond_read* primitives are not proper fallbacks
>    and got moved into linux/atomic.c. No arch_ variants are
>    generated because the base primitives smp_cond_load*()
>    are instrumented.
> 
>  - once all architectures are moved over to arch_atomic_ we can remove
>    one of the fallback variants and reclaim some 2300 lines.
> 
>  - atomic_{read,set}*() are no longer double-instrumented
> 
> Reported-by: Thomas Gleixner <tglx@...utronix.de>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Mark Rutland <mark.rutland@....com>
>