include/linux/seq_file.h | 1 - include/linux/string.h | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-)
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")
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(-)
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index d6ebf0596510..2fb266ea69fa 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -181,7 +181,6 @@ int seq_open_private(struct file *, const struct seq_operations *, int);
int seq_release_private(struct inode *, struct file *);
#ifdef CONFIG_BINARY_PRINTF
-__printf(2, 0)
void seq_bprintf(struct seq_file *m, const char *f, const u32 *binary);
#endif
diff --git a/include/linux/string.h b/include/linux/string.h
index 1b564c36d721..b850bd91b3d8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -336,8 +336,8 @@ int __sysfs_match_string(const char * const *array, size_t n, const char *s);
#define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), _s)
#ifdef CONFIG_BINARY_PRINTF
-__printf(3, 0) int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
-__printf(3, 0) int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
+int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
+int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
#endif
extern ssize_t memory_read_from_buffer(void *to, size_t count, loff_t *ppos,
--
2.39.5
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
On Thu, Feb 5, 2026, at 09:53, Petr Mladek wrote:
> On Wed 2026-02-04 14:26:23, Arnd Bergmann wrote:
>> 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.
Unfortunately, I have not been able to reproduce the original
warnings at all. The va_format() warning and the patch to
silence that look entirely unrelated here, that was just the
compiler incorrectly identifying a function that does not even
take a format argument.
I'm sure some other intermediate change managed to shut up
the warnings, but I don't know which one. My best guess would
be that 938df695e98d ("vsprintf: associate the format state with
the format pointer") made gcc no longer warn about bstr_printf(),
but that predates Andy's patch and I can't easily revert it for
testing. Checking out a kernel before those patches does have
the warning on va_format() but not on the other ones.
>> 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?
I think your tree makes most sense here, but I have no strong
preference.
Arnd
On Thu, Feb 5, 2026 at 2:13 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Feb 5, 2026, at 09:53, Petr Mladek wrote:
> > On Wed 2026-02-04 14:26:23, Arnd Bergmann wrote:
> >> 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.
>
> Unfortunately, I have not been able to reproduce the original
> warnings at all. The va_format() warning and the patch to
> silence that look entirely unrelated here, that was just the
> compiler incorrectly identifying a function that does not even
> take a format argument.
>
> I'm sure some other intermediate change managed to shut up
> the warnings, but I don't know which one. My best guess would
> be that 938df695e98d ("vsprintf: associate the format state with
> the format pointer") made gcc no longer warn about bstr_printf(),
> but that predates Andy's patch and I can't easily revert it for
> testing. Checking out a kernel before those patches does have
> the warning on va_format() but not on the other ones.
>
> >> 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?
>
> I think your tree makes most sense here, but I have no strong
> preference.
As long as it makes into the upcoming merge window any tree is fine.
Let's go via printk.
On Thu 2026-02-05 07:58:10, Alexei Starovoitov wrote:
> On Thu, Feb 5, 2026 at 2:13 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thu, Feb 5, 2026, at 09:53, Petr Mladek wrote:
> > > On Wed 2026-02-04 14:26:23, Arnd Bergmann wrote:
> > >> 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.
> >
> > Unfortunately, I have not been able to reproduce the original
> > warnings at all. The va_format() warning and the patch to
> > silence that look entirely unrelated here, that was just the
> > compiler incorrectly identifying a function that does not even
> > take a format argument.
> >
> > I'm sure some other intermediate change managed to shut up
> > the warnings, but I don't know which one. My best guess would
> > be that 938df695e98d ("vsprintf: associate the format state with
> > the format pointer") made gcc no longer warn about bstr_printf(),
> > but that predates Andy's patch and I can't easily revert it for
> > testing. Checking out a kernel before those patches does have
> > the warning on va_format() but not on the other ones.
OK. The commit will include link to this thread. It should be good
enough ;-)
> > > I wonder who should take this patch. Should it go via
> > > printk/bpf/tracing or another tree?
> > > Does anyone has any preference, please?
> >
> > I think your tree makes most sense here, but I have no strong
> > preference.
>
> As long as it makes into the upcoming merge window any tree is fine.
> Let's go via printk.
OK, I have committed the patch into printk/linux.git, branch for-6.20.
Best Regards,
Petr
On Wed, Feb 04, 2026 at 02:26:23PM +0100, Arnd Bergmann wrote: > 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. Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.