vsnprintf: drop __printf() attributes on binary printing functions

PATCH Applied Arnd Bergmann 6 participants 7 messages Feb 4 – Feb 12

Subsystems (2)

BPF Generic string library

lore

Share & tools

lore

Arnd Bergmann

author

2026-02-04 13:26 UTC #0 lore raw

PATCH 1/1 vsnprintf: drop __printf() attributes on binary printing functions

From: Arnd Bergmann <[email protected]>

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/ open here

Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here

Reported-by kernel test robot <[email protected]>

Acked-by Alexei Starovoitov <[email protected]>

Signed-off-by Arnd Bergmann <[email protected]>

---
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/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/

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(-)

include/linux/seq_file.h +0 -1

index d6ebf0596510..2fb266ea69fa 100644
@@ -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

include/linux/string.h +2 -2

index 1b564c36d721..b850bd91b3d8 100644
@@ -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,

Signature · 1 line

2.39.5

Andy Shevchenko

Acked-by on v1 1/1

2026-02-04 13:47 UTC #1 lore raw

Quoted 13 lines · Arnd Bergmann

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.

Quoted 6 lines

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 <[email protected]>

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Petr Mladek

Acked-by on v1 1/1

2026-02-05 08:54 UTC #2 lore raw

In reply to Arnd Bergmann

Quoted 19 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>
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.

Quoted 5 lines

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/[email protected]/#t

It would be worth to mentionin this in the commit message.

Quoted 14 lines

Link https://lore.kernel.org/all/CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com/ open here
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Reported-by kernel test robot <[email protected]>
Suggested-by Alexei Starovoitov <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Signed-off-by Arnd Bergmann <[email protected]>
---
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/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/

Quoted 5 lines

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 <[email protected]>

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

Arnd Bergmann

2026-02-05 10:13 UTC #3 lore raw

Quoted 7 lines · Petr Mladek

Quoted 2 lines · Arnd Bergmann
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.

Quoted 7 lines

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/[email protected]/#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.

Quoted 20 lines

Quoted 14 lines
Link https://lore.kernel.org/all/CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com/ open here
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Reported-by kernel test robot <[email protected]>
Suggested-by Alexei Starovoitov <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Signed-off-by Arnd Bergmann <[email protected]>
---
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/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
Quoted 5 lines
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(-)

Quoted 8 lines

Otherwise, the change looks good to me. Feel free to use, ideally with the updated commit message:
Acked-by Petr Mladek <[email protected]>
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

Alexei Starovoitov

2026-02-05 15:58 UTC #4 lore raw

Quoted 54 lines · Arnd Bergmann

Quoted 7 lines · Petr Mladek
Quoted 2 lines · Arnd Bergmann
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.
Quoted 7 lines
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/[email protected]/#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.
Quoted 23 lines
Quoted 14 lines
Link https://lore.kernel.org/all/CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com/ open here
Closes https://lore.kernel.org/oe-kbuild-all/[email protected]/ open here
Reported-by kernel test robot <[email protected]>
Suggested-by Alexei Starovoitov <[email protected]>
Acked-by Alexei Starovoitov <[email protected]>
Signed-off-by Arnd Bergmann <[email protected]>
---
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/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
Quoted 5 lines
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:

Quoted 8 lines

Quoted 5 lines
Acked-by Petr Mladek <[email protected]>
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.

Petr Mladek

2026-02-06 09:28 UTC #5 lore raw

Quoted 24 lines · Alexei Starovoitov

Quoted 23 lines · Arnd Bergmann
Quoted 7 lines · Petr Mladek
Quoted 2 lines · Arnd Bergmann
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.
Quoted 7 lines
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/[email protected]/#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.

Quoted 7 lines

Quoted 7 lines
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 ;-)

Quoted 9 lines

Quoted 6 lines
Quoted 3 lines
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

[email protected]

CI Applied

2026-02-12 01:28 UTC #6 lore raw

In reply to Arnd Bergmann

This patch was applied to bpf/bpf-next.git (master) by Petr Mladek <[email protected]>:

Hello:

This patch was applied to bpf/bpf-next.git (master) by Petr Mladek <[email protected]>:

Quoted 6 lines · On Wed, 4 Feb 2026 14:26:23 +0100 you wrote:

From: Arnd Bergmann <[email protected]>
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:

Quoted 6 lines

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);
| ^~~
[...]

Here is the summary with links:
- vsnprintf: drop __printf() attributes on binary printing functions

    https://git.kernel.org/bpf/bpf-next/c/b07829d546c8

You are awesome, thank you!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html