linux-kernel - Re: [PATCH v2] srcu: avoid escaped section names

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:   Mon, 5 Oct 2020 23:56:23 -0700
From:   Nathan Chancellor <natechancellor@...il.com>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Sedat Dilek <sedat.dilek@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Josh Triplett <josh@...htriplett.org>,
        Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>, rcu@...r.kernel.org,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH v2] srcu: avoid escaped section names

On Mon, Oct 05, 2020 at 11:49:10AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 05, 2020 at 08:38:42PM +0200, Sedat Dilek wrote:
> > On Mon, Oct 5, 2020 at 8:29 PM 'Nick Desaulniers' via Clang Built
> > Linux <clang-built-linux@...glegroups.com> wrote:
> > >
> > > On Fri, Oct 2, 2020 at 1:51 PM Paul E. McKenney <paulmck@...nel.org> wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 01:55:48PM -0700, Nick Desaulniers wrote:
> > > > > On Wed, Sep 30, 2020 at 1:40 PM Paul E. McKenney <paulmck@...nel.org> wrote:
> > > > > >
> > > > > > On Tue, Sep 29, 2020 at 12:25:49PM -0700, Nick Desaulniers wrote:
> > > > > > > The stringification operator, `#`, in the preprocessor escapes strings.
> > > > > > > For example, `# "foo"` becomes `"\"foo\""`.  GCC and Clang differ in how
> > > > > > > they treat section names that contain \".
> > > > > > >
> > > > > > > The portable solution is to not use a string literal with the
> > > > > > > preprocessor stringification operator.
> > > > > > >
> > > > > > > Link: https://bugs.llvm.org/show_bug.cgi?id=42950
> > > > > > > Fixes: commit fe15b50cdeee ("srcu: Allocate per-CPU data for DEFINE_SRCU() in modules")
> > > > > > > Signed-off-by: Nick Desaulniers <ndesaulniers@...gle.com>
> > > > > >
> > > > > > I am guessing that this needs to go up with other patches.  If so:
> > > > > >
> > > > > > Acked-by: Paul E. McKenney <paulmck@...nel.org>
> > > > > >
> > > > > > If not, let me know and I will queue it.
> > > > >
> > > > > I could have bundled them up as a series.  I think you can pick it up,
> > > > > and I'll owe you a beer?
> > > >
> > > > It is queued, thank you!
> > > >
> > > > When does it need to hit mainline?  (Your default is the v5.11 merge
> > > > window, that is, the one following the upcoming merge window.)
> > >
> > > No rush, this patch wasn't blocking any known issue, just a cleanup
> > > while I was in the neighborhood.  100 years ago, I was an Eagle scout.
> > > Pretty sure there was a motto about "leaving things better than you
> > > found them."  Thanks for help resolving the merge conflict reported in
> > > -next related to it.
> > 
> > Wasn't there a problem with your "Fixes:" tag (Fixes: *drop word
> > "commit"* commit_hashid ("...")?
> 
> Indeed there was, and I have it noted to be fixed on my next rebase.
> 
> Perhaps another reason not to rush to mainline though.  ;-)
> 
> 							Thanx, Paul

I am replying here as well so that the relevant parties are in the know
but I believe this patch should be fast tracked with a cc stable tag as
this appears to be the root cause of the issue that Nick reported a few
weeks ago:

https://lore.kernel.org/rcu/CAKwvOdm4AQhobdkKT08bjPGb15N58QN79XWxEaQt-P5Dk4+avQ@mail.gmail.com/
https://github.com/ClangBuiltLinux/linux/issues/1081

I can reproduce the issue on next-20201002 on my Raspberry Pi 4 just by
booting it up. As soon as I apply this patch, all warnings disappear. I
asked the original reporters to test if the patch resolves the issue for
them but I figured more visibility on this, the sooner. The commit
message might need to be revised if this turns out to be the case to
make it more apparent that it has a user visible issue, rather than just
a QoL fix.

Additionally, it seems like the patch is missing some reviewed by tags
from Kees, Sedat, and myself. Feel free to add a

Tested-by: Nathan Chancellor <natechancellor@...il.com>

as well.

Cheers,
Nathan