Re: [PATCH v2] srcu: avoid escaped section names

[Nathan Chancellor <natechancellor@gmail.com>]

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@googlegroups.com> wrote:
> > >
> > > On Fri, Oct 2, 2020 at 1:51 PM Paul E. McKenney <paulmck@kernel.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@kernel.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@google.com>
> > > > > >
> > > > > > I am guessing that this needs to go up with other patches.  If so:
> > > > > >
> > > > > > Acked-by: Paul E. McKenney <paulmck@kernel.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@gmail.com>

as well.

Cheers,
Nathan