linux-kernel - Re: [PATCH] bug: hush suggest-attribute=format for __warn

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]

Message-ID: <DEZJ0FR59QNW.AP4SRYAQV8O5@google.com>
Date: Tue, 16 Dec 2025 09:16:41 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: Brendan Jackman <jackmanb@...gle.com>, <linux-kernel@...r.kernel.org>, <kees@...nel.org>, 
	<acarmina@...hat.com>, <jpoimboe@...nel.org>, <mark.rutland@....com>, 
	<maciej.wieczor-retman@...el.com>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] bug: hush suggest-attribute=format for __warn_printf()

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@...gle.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?