From: Petr Mladek <pmladek@suse.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>, kernel test robot <lkp@intel.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Andy Shevchenko <andy@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH] vsnprintf: drop __printf() attributes on binary printing functions
Date: Thu, 5 Feb 2026 09:53:57 +0100 [thread overview]
Message-ID: <aYRapf5K8wFGEO8v@pathway.suse.cz> (raw)
In-Reply-To: <20260204132643.1302967-1-arnd@kernel.org>
On Wed 2026-02-04 14:26:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The printf() format attributes are applied inconsistently for the binary
> printf helpers, which causes warnings for the bpf_trace code using
> them from functions that pass down format strings:
>
> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
> | ^~~
>
> This can be addressed either by annotating all five callers in bpf code,
> or by removing the annotations on the callees that were added by Andy
> Shevchenko last year.
>
> As Alexei Starovoitov points out, there are no callers in C code that
> would benefit from the __printf attributes, the only users are in BPF
> code or in the do_trace_printk() helper that already checks the arguments.
>
> Drop all three of these annotations, reverting the earlierl commits that
> added these, in order to get a clean build with -Wsuggest-attribute=format.
>
> Fixes: 6b2c1e30ad68 ("seq_file: Mark binary printing functions with __printf() attribute")
> Fixes: 7bf819aa992f ("vsnprintf: Mark binary printing functions with __printf() attribute")
From the commit message, it is not obvious why reverting these commits
won't bring back the warnings in the modified functions.
My understanding is that the warnings won't get back thanks to
the commit bd67c1c3c353b6560 ("vsnprintf: Silence false positive
GCC warning for va_format()") as explained by the original cover
letter, see
https://lore.kernel.org/all/20250321144822.324050-1-andriy.shevchenko@linux.intel.com/#t
It would be worth to mentionin this in the commit message.
> Link: https://lore.kernel.org/all/CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202512061640.9hKTnB8p-lkp@intel.com/
> Reported-by: kernel test robot <lkp@intel.com>
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Acked-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> For reference, three additional patches are required before we can drop
> the Makefile.warn line that currently hides these warnings:
>
> https://lore.kernel.org/lkml/20260203162546.2254900-1-arnd@kernel.org/
> https://lore.kernel.org/lkml/20260203163440.2674340-1-arnd@kernel.org/
> https://lore.kernel.org/lkml/20260203164545.3174910-1-arnd@kernel.org/
>
> Tested using randconfig builds on arm/arm64/x86
> ---
> include/linux/seq_file.h | 1 -
> include/linux/string.h | 4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
Otherwise, the change looks good to me. Feel free to use,
ideally with the updated commit message:
Acked-by: Petr Mladek <pmladek@suse.com>
I wonder who should take this patch. Should it go via
printk/bpf/tracing or another tree?
Does anyone has any preference, please?
Best Regards,
Petr
next prev parent reply other threads:[~2026-02-05 8:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 13:26 [PATCH] vsnprintf: drop __printf() attributes on binary printing functions Arnd Bergmann
2026-02-04 13:47 ` Andy Shevchenko
2026-02-05 8:53 ` Petr Mladek [this message]
2026-02-05 10:12 ` Arnd Bergmann
2026-02-05 15:58 ` Alexei Starovoitov
2026-02-06 9:28 ` Petr Mladek
2026-02-12 1:28 ` patchwork-bot+netdevbpf
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=aYRapf5K8wFGEO8v@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy@kernel.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brgl@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
/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