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]

Message-ID: <20200508084007.GQ5298@hirez.programming.kicks-ass.net>
Date:   Fri, 8 May 2020 10:40:07 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        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>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [patch V4 part 1 07/36] locking/atomics: Flip fallbacks and
 instrumentation

On Thu, May 07, 2020 at 07:41:27PM -0400, Steven Rostedt wrote:
> 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.

Even I can get git-log to tell me what the next patch is, and I'm an
absolute disaster with git. But yes, valid point.

> 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?

No, the next patch was part4-2, so it already isn't accurate.