The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Brendan Jackman <jackmanb@google.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Brendan Jackman <jackmanb@google.com>,
	<linux-kernel@vger.kernel.org>, <kees@kernel.org>,
	 <acarmina@redhat.com>, <jpoimboe@kernel.org>,
	<mark.rutland@arm.com>,  <maciej.wieczor-retman@intel.com>,
	 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()
Date: Tue, 16 Dec 2025 09:16:41 +0000	[thread overview]
Message-ID: <DEZJ0FR59QNW.AP4SRYAQV8O5@google.com> (raw)
In-Reply-To: <20251216084949.GQ3707837@noisy.programming.kicks-ass.net>

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?


  reply	other threads:[~2025-12-16  9:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-07  3:53 [PATCH] bug: hush suggest-attribute=format for __warn_printf() Brendan Jackman
2025-12-08  8:38 ` Peter Zijlstra
2025-12-08  8:50   ` Brendan Jackman
2025-12-08  8:58     ` Peter Zijlstra
2025-12-09  9:16 ` [tip: core/urgent] bug: Hush " tip-bot2 for Brendan Jackman
2025-12-12  9:10 ` tip-bot2 for Brendan Jackman
2025-12-12  9:29 ` tip-bot2 for Brendan Jackman
2025-12-16  4:24 ` [PATCH] bug: hush " Andrew Morton
2025-12-16  8:49   ` Peter Zijlstra
2025-12-16  9:16     ` Brendan Jackman [this message]
2025-12-16 12:36       ` David Laight
2025-12-16 12:43         ` Brendan Jackman

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=DEZJ0FR59QNW.AP4SRYAQV8O5@google.com \
    --to=jackmanb@google.com \
    --cc=acarmina@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox