[PATCH] bug: hush suggest-attribute=format for __warn_printf()

[PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Brendan Jackman]

Recent additions to this function cause GCC 14.3.0 to get excited and
suggest a missing attribute:

lib/bug.c: In function ‘__warn_printf’:
lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
  187 |                         vprintk(fmt, *args);
      |                         ^~~~~~~

Disable the diagnostic locally, following the pattern used for stuff
like va_format().

Fixes: 5c47b7f3d1a9 ("bug: Add BUG_FORMAT_ARGS infrastructure")
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 lib/bug.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/bug.c b/lib/bug.c
index edd9041f89f3aa613af71e4f107b52a4f4dc71f4..051891f874439d66f907e043cf52b954b3ea564b 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -173,6 +173,9 @@ struct bug_entry *find_bug(unsigned long bugaddr)
 	return module_find_bug(bugaddr);
 }
 
+__diag_push();
+__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
+	      "Not a valid __printf() conversion candidate.");
 static void __warn_printf(const char *fmt, struct pt_regs *regs)
 {
 	if (!fmt)
@@ -192,6 +195,7 @@ static void __warn_printf(const char *fmt, struct pt_regs *regs)
 
 	printk("%s", fmt);
 }
+__diag_pop();
 
 static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long bugaddr, struct pt_regs *regs)
 {

---
base-commit: 5e8f8a25efb277ac6f61f553f0c533ff1402bd7c
change-id: 20251207-warn-printf-gcc-8da08c251c1c

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Peter Zijlstra]

On Sun, Dec 07, 2025 at 03:53:18AM +0000, Brendan Jackman wrote:
> Recent additions to this function cause GCC 14.3.0 to get excited and
> suggest a missing attribute:
> 
> lib/bug.c: In function ‘__warn_printf’:
> lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
>   187 |                         vprintk(fmt, *args);
>       |                         ^~~~~~~
> 
> Disable the diagnostic locally, following the pattern used for stuff
> like va_format().

No real objection, but why haven't I seen this in my own builds? Most of
my machines are on gcc-14 / gcc-15.

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Brendan Jackman]

On Mon Dec 8, 2025 at 8:38 AM UTC, Peter Zijlstra wrote:
> On Sun, Dec 07, 2025 at 03:53:18AM +0000, Brendan Jackman wrote:
>> Recent additions to this function cause GCC 14.3.0 to get excited and
>> suggest a missing attribute:
>> 
>> lib/bug.c: In function ‘__warn_printf’:
>> lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
>>   187 |                         vprintk(fmt, *args);
>>       |                         ^~~~~~~
>> 
>> Disable the diagnostic locally, following the pattern used for stuff
>> like va_format().
>
> No real objection, but why haven't I seen this in my own builds? Most of
> my machines are on gcc-14 / gcc-15.

Ah, yeah, apparently it only shows up with W=1.

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Peter Zijlstra]

On Mon, Dec 08, 2025 at 08:50:17AM +0000, Brendan Jackman wrote:
> On Mon Dec 8, 2025 at 8:38 AM UTC, Peter Zijlstra wrote:
> > On Sun, Dec 07, 2025 at 03:53:18AM +0000, Brendan Jackman wrote:
> >> Recent additions to this function cause GCC 14.3.0 to get excited and
> >> suggest a missing attribute:
> >> 
> >> lib/bug.c: In function ‘__warn_printf’:
> >> lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
> >>   187 |                         vprintk(fmt, *args);
> >>       |                         ^~~~~~~
> >> 
> >> Disable the diagnostic locally, following the pattern used for stuff
> >> like va_format().
> >
> > No real objection, but why haven't I seen this in my own builds? Most of
> > my machines are on gcc-14 / gcc-15.
> 
> Ah, yeah, apparently it only shows up with W=1.

*sigh*, one of them.

Ok, thanks!

[tip: core/urgent] bug: Hush suggest-attribute=format for __warn_printf()

[tip-bot2 for Brendan Jackman]

The following commit has been merged into the core/urgent branch of tip:

Commit-ID:     40f40edaa30137fe7f09752db60a7a6ab4124ef9
Gitweb:        https://git.kernel.org/tip/40f40edaa30137fe7f09752db60a7a6ab4124ef9
Author:        Brendan Jackman <jackmanb@google.com>
AuthorDate:    Sun, 07 Dec 2025 03:53:18 
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 09 Dec 2025 10:14:47 +01:00

bug: Hush suggest-attribute=format for __warn_printf()

Recent additions to this function cause GCC 14.3.0 to get excited
(W=1) and suggest a missing attribute:

lib/bug.c: In function â=80=98__warn_printfâ=80=99:
lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
  187 |                         vprintk(fmt, *args);
      |                         ^~~~~~~

Disable the diagnostic locally, following the pattern used for stuff
like va_format().

Fixes: 5c47b7f3d1a9 ("bug: Add BUG_FORMAT_ARGS infrastructure")
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20251207-warn-printf-gcc-v1-1-b597d612b94b@google.com
---
 lib/bug.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/bug.c b/lib/bug.c
index c6f691f..623c467 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -173,6 +173,9 @@ struct bug_entry *find_bug(unsigned long bugaddr)
 	return module_find_bug(bugaddr);
 }
 
+__diag_push();
+__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
+	      "Not a valid __printf() conversion candidate.");
 static void __warn_printf(const char *fmt, struct pt_regs *regs)
 {
 	if (!fmt)
@@ -192,6 +195,7 @@ static void __warn_printf(const char *fmt, struct pt_regs *regs)
 
 	printk("%s", fmt);
 }
+__diag_pop();
 
 static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long bugaddr, struct pt_regs *regs)
 {

[tip: core/urgent] bug: Hush suggest-attribute=format for __warn_printf()

[tip-bot2 for Brendan Jackman]

The following commit has been merged into the core/urgent branch of tip:

Commit-ID:     41a1dcfb7ade1051bdc6e4923099699f45fcbb10
Gitweb:        https://git.kernel.org/tip/41a1dcfb7ade1051bdc6e4923099699f45fcbb10
Author:        Brendan Jackman <jackmanb@google.com>
AuthorDate:    Sun, 07 Dec 2025 03:53:18 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 12 Dec 2025 10:06:02 +01:00

bug: Hush suggest-attribute=format for __warn_printf()

Recent additions to this function cause GCC 14.3.0 to get excited
(W=1) and suggest a missing attribute:

	lib/bug.c: In function '__warn_printf':
	lib/bug.c:187:25: error: function '__warn_printf' be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
	  187 |                         vprintk(fmt, *args);
	      |                         ^~~~~~~

Disable the diagnostic locally, following the pattern used for stuff
like va_format().

Fixes: 5c47b7f3d1a9 ("bug: Add BUG_FORMAT_ARGS infrastructure")
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20251207-warn-printf-gcc-v1-1-b597d612b94b@google.com
---
 lib/bug.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/bug.c b/lib/bug.c
index c6f691f..623c467 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -173,6 +173,9 @@ struct bug_entry *find_bug(unsigned long bugaddr)
 	return module_find_bug(bugaddr);
 }
 
+__diag_push();
+__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
+	      "Not a valid __printf() conversion candidate.");
 static void __warn_printf(const char *fmt, struct pt_regs *regs)
 {
 	if (!fmt)
@@ -192,6 +195,7 @@ static void __warn_printf(const char *fmt, struct pt_regs *regs)
 
 	printk("%s", fmt);
 }
+__diag_pop();
 
 static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long bugaddr, struct pt_regs *regs)
 {

[tip: core/urgent] bug: Hush suggest-attribute=format for __warn_printf()

[tip-bot2 for Brendan Jackman]

The following commit has been merged into the core/urgent branch of tip:

Commit-ID:     d36067d6ea00827e9b8fc087d8216710cb99b3cf
Gitweb:        https://git.kernel.org/tip/d36067d6ea00827e9b8fc087d8216710cb99b3cf
Author:        Brendan Jackman <jackmanb@google.com>
AuthorDate:    Sun, 07 Dec 2025 03:53:18 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 12 Dec 2025 10:26:26 +01:00

bug: Hush suggest-attribute=format for __warn_printf()

Recent additions to this function cause GCC 14.3.0 to get excited
(W=1) and suggest a missing attribute:

	lib/bug.c: In function '__warn_printf':
	lib/bug.c:187:25: error: function '__warn_printf' be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
	  187 |                         vprintk(fmt, *args);
	      |                         ^~~~~~~

Disable the diagnostic locally, following the pattern used for stuff
like va_format().

Fixes: 5c47b7f3d1a9 ("bug: Add BUG_FORMAT_ARGS infrastructure")
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20251207-warn-printf-gcc-v1-1-b597d612b94b@google.com
---
 lib/bug.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/bug.c b/lib/bug.c
index c6f691f..623c467 100644
--- a/lib/bug.c
+++ b/lib/bug.c
@@ -173,6 +173,9 @@ struct bug_entry *find_bug(unsigned long bugaddr)
 	return module_find_bug(bugaddr);
 }
 
+__diag_push();
+__diag_ignore(GCC, all, "-Wsuggest-attribute=format",
+	      "Not a valid __printf() conversion candidate.");
 static void __warn_printf(const char *fmt, struct pt_regs *regs)
 {
 	if (!fmt)
@@ -192,6 +195,7 @@ static void __warn_printf(const char *fmt, struct pt_regs *regs)
 
 	printk("%s", fmt);
 }
+__diag_pop();
 
 static enum bug_trap_type __report_bug(struct bug_entry *bug, unsigned long bugaddr, struct pt_regs *regs)
 {

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Andrew Morton]

On Sun, 07 Dec 2025 03:53:18 +0000 Brendan Jackman <jackmanb@google.com> wrote:

> Recent additions to this function cause GCC 14.3.0 to get excited and
> suggest a missing attribute:
> 
> lib/bug.c: In function ‘__warn_printf’:
> lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
>   187 |                         vprintk(fmt, *args);
>       |                         ^~~~~~~
> 
> Disable the diagnostic locally, following the pattern used for stuff
> like va_format().
> 

Question please.  Why are we suppressing the warning instead of
addressing it, as Andy attempts to do in
https://lkml.kernel.org/r/20251208141618.2805983-1-andriy.shevchenko@linux.intel.com?

I went off and looked at the commit which did this to va_format() but
it didn't tell me.

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Peter Zijlstra]

On Mon, Dec 15, 2025 at 08:24:30PM -0800, Andrew Morton wrote:
> On Sun, 07 Dec 2025 03:53:18 +0000 Brendan Jackman <jackmanb@google.com> wrote:
> 
> > Recent additions to this function cause GCC 14.3.0 to get excited and
> > suggest a missing attribute:
> > 
> > lib/bug.c: In function ‘__warn_printf’:
> > lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
> >   187 |                         vprintk(fmt, *args);
> >       |                         ^~~~~~~
> > 
> > Disable the diagnostic locally, following the pattern used for stuff
> > like va_format().
> > 
> 
> Question please.  Why are we suppressing the warning instead of
> addressing it, as Andy attempts to do in
> https://lkml.kernel.org/r/20251208141618.2805983-1-andriy.shevchenko@linux.intel.com?
> 
> I went off and looked at the commit which did this to va_format() but
> it didn't tell me.

Blergh, I hadn't even noticed Andy's thing was different :/

Fundamentally I'm starting to hate W=1. Either we think these warnings
are good and we should get it into the default build, or we don't think
and we should just collectively ignore them.

This stream of W=1 'fixes' every time is getting really rather tedious.

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Brendan Jackman]

On Tue Dec 16, 2025 at 8:49 AM UTC, Peter Zijlstra wrote:
> On Mon, Dec 15, 2025 at 08:24:30PM -0800, Andrew Morton wrote:
>> On Sun, 07 Dec 2025 03:53:18 +0000 Brendan Jackman <jackmanb@google.com> wrote:
>> 
>> > Recent additions to this function cause GCC 14.3.0 to get excited and
>> > suggest a missing attribute:
>> > 
>> > lib/bug.c: In function ‘__warn_printf’:
>> > lib/bug.c:187:25: error: function ‘__warn_printf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format]
>> >   187 |                         vprintk(fmt, *args);
>> >       |                         ^~~~~~~
>> > 
>> > Disable the diagnostic locally, following the pattern used for stuff
>> > like va_format().
>> > 
>> 
>> Question please.  Why are we suppressing the warning instead of
>> addressing it, as Andy attempts to do in
>> https://lkml.kernel.org/r/20251208141618.2805983-1-andriy.shevchenko@linux.intel.com?

Hm. I thought this warning was a false positive, maybe I don't
understand what the printf attribute means here. I will read up on it
and comment on that other thread. 

If that other one gets merged let's just revert this in the TIP tree (or
roll the branch back if that's acceptable).

>> I went off and looked at the commit which did this to va_format() but
>> it didn't tell me.

Yeah sorry, I should have actually described this in the commit message,
then if I was wrong it would have been obvious.

> Blergh, I hadn't even noticed Andy's thing was different :/
>
> Fundamentally I'm starting to hate W=1. Either we think these warnings
> are good and we should get it into the default build, or we don't think
> and we should just collectively ignore them.

I agree. I like setting W=1 for building my own code, I prefer the most
pedantic compiler possible. But, this is only useful if the code I'm
building on is clean of warnings. So either W=1 builds have to be
supported (in which case why not make it default?) or we should give up
on them since they aren't considered useful enough to justify the
effort.

Given the kernel is usually W=1 clean, it seems like we _do_ support it.
It's just that we support it via these akwkward retroactive fixups
instead of just expecting code to be W=1-clean before we merge it?

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[David Laight]

On Tue, 16 Dec 2025 09:16:41 +0000
Brendan Jackman <jackmanb@google.com> wrote:

...
> Given the kernel is usually W=1 clean, it seems like we _do_ support it.
> It's just that we support it via these akwkward retroactive fixups
> instead of just expecting code to be W=1-clean before we merge it?

It's not that W=1 clean, the bot remembers which warnings it has seen and
only reports new ones.

There are some entirely annoying ones that haven't been moved to W=2.
Some need fixing in the compiler, for instance:
int foo[] = { [0 ... 3 ] = -1, [2] = 1 };
(to change the default initialiser)
generates a warning because [2] is initialised twice.
Any attempt to 'fix' that is likely to leave an unexpected 0 entry.

The 'suggest-attribute-format' one used to give false positives on
some architectures (IIRC including x86) for some vprintf-like functions
because va_list is 'char *'.
That must not be true for kernel builds (any more).

	David

Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

[Brendan Jackman]

On Tue, 16 Dec 2025 at 13:36, David Laight <david.laight.linux@gmail.com> wrote:
>
> On Tue, 16 Dec 2025 09:16:41 +0000
> Brendan Jackman <jackmanb@google.com> wrote:
>
> ...
> > Given the kernel is usually W=1 clean, it seems like we _do_ support it.
> > It's just that we support it via these akwkward retroactive fixups
> > instead of just expecting code to be W=1-clean before we merge it?
>
> It's not that W=1 clean, the bot remembers which warnings it has seen and
> only reports new ones.

I haven't been doing it for long, but I build with W=1 in Github
Actions [0] and this suggest-attribute-format is the first issue
that's come up there. I don't have any logic to exclude pre-existing
errors.

I am only building a pretty small config there (enough to run a few
selftests on QEMU) but it does suggest that people "support" W=1 at
least for the core kernel code.

[0] https://github.com/bjackman/limmat-kernel-nix