From: Petr Mladek <pmladek@suse.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <kees@kernel.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15
Date: Fri, 4 Apr 2025 10:19:02 +0200 [thread overview]
Message-ID: <Z--V04jtF16r63eO@pathway.suse.cz> (raw)
In-Reply-To: <Z-557YrwVr8bONq4@smile.fi.intel.com>
On Thu 2025-04-03 15:07:09, Andy Shevchenko wrote:
> On Wed, Apr 02, 2025 at 01:34:22PM -0700, Nathan Chancellor wrote:
> > On Wed, Apr 02, 2025 at 10:25:46PM +0300, Andy Shevchenko wrote:
> > > +Cc: Kees and Nathan (I believe this discussion has some material for
> > > you, folks, to think of / comment on / etc)
> >
> > Thanks, I have commented on the part of the message that seem relevant
> > for me.
>
> Thank you!
>
> > > On Wed, Apr 2, 2025 at 10:06 PM Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > On Wed, 2 Apr 2025 at 11:39, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > > >
> > > > > Yes. Clang complains on unknown pragma.
> > > >
> > > > Can we please use wrapper defines instead so that we don't have that
> > > > #ifndef in the middle of code? And since those don't work with
> > > > '#pragma', they need to use the _Pragma() operator instead.
> > > >
> > > > Something like
> > > >
> > > > #define GCC_PRAGMA(x) _Pragma(#x)
> > > >
> > > > in compiler-gcc.h, and then add a
> > > >
> > > > #ifndef GCC_PRAGMA
> > > > #define GCC_PRAGMA(x) /* Nothing */
> > > > #endif
> > > >
> > > > and then you can just do
> > > >
> > > > GCC_PRAGMA(Wsuggest-attribute=format)
> > > >
> > > > in places like this?
> > > >
> > > > (Entirely untested: I *despise* pragma in general).
> >
> > We have the __diag() infrastructure for this already. I think this issue
> > would be as simple as the following diff, which makes clang and GCC
> > happy without any obvious ifdeffery.
>
> FWIW, I have tested this in my case for both compilers and they are happy with it.
>
> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Great!
Nathan, would mind to send this as a proper patch, please?
> > diff --git a/include/linux/compiler-igcc.h b/include/linux/compiler-gcc.h
> > index 32048052c64a..5d07c469b571 100644
> > --- a/include/linux/compiler-gcc.h
> > +++ b/include/linux/compiler-gcc.h
> > @@ -127,6 +127,8 @@
> > #define __diag_GCC_8(s)
> > #endif
> >
> > +#define __diag_GCC_all(s) __diag(s)
> > +
> > #define __diag_ignore_all(option, comment) \
> > __diag(__diag_GCC_ignore option)
> >
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 01699852f30c..6ff4d85e144e 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1699,10 +1699,8 @@ char *escaped_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
> > return buf;
> > }
> >
> > -#pragma GCC diagnostic push
> > -#ifndef __clang__
> > -#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> > -#endif
> > +__diag_push();
> > +__diag_ignore(GCC, all, "-Wsuggest-attribute=format", "<reason>");
> > static char *va_format(char *buf, char *end, struct va_format *va_fmt,
> > struct printf_spec spec)
> > {
> > @@ -1717,7 +1715,7 @@ static char *va_format(char *buf, char *end, struct va_format *va_fmt,
> >
> > return buf;
> > }
> > -#pragma GCC diagnostic pop
> > +__diag_pop();
> >
> > static noinline_for_stack
> > char *uuid_string(char *buf, char *end, const u8 *addr,
Best Regards,
Petr
next prev parent reply other threads:[~2025-04-04 8:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 12:58 [GIT PULL] more printk for 6.15 Petr Mladek
2025-04-02 17:12 ` Linus Torvalds
2025-04-02 18:39 ` Andy Shevchenko
2025-04-02 19:06 ` Linus Torvalds
2025-04-02 19:25 ` Andy Shevchenko
2025-04-02 20:34 ` Nathan Chancellor
2025-04-03 12:07 ` Andy Shevchenko
2025-04-04 8:19 ` Petr Mladek [this message]
2025-04-04 21:02 ` Nathan Chancellor
2025-04-03 16:14 ` Kees Cook
2025-04-02 19:07 ` Linus Torvalds
2025-04-02 19:10 ` Linus Torvalds
2025-04-02 19:44 ` Steven Rostedt
2025-04-02 19:52 ` Linus Torvalds
2025-04-02 20:25 ` Andy Shevchenko
2025-04-02 20:00 ` Sean Christopherson
2025-04-02 20:11 ` Steven Rostedt
2025-04-03 9:34 ` Petr Mladek
2025-04-02 17:48 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z--V04jtF16r63eO@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=john.ogness@linutronix.de \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.