linux-kernel - Re: [PATCH] bpf: add missing _

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: <CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com>
Date: Tue, 3 Feb 2026 10:11:49 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Song Liu <song@...nel.org>, 
	KP Singh <kpsingh@...nel.org>, Matt Bobrowski <mattbobrowski@...gle.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Mykyta Yatsenko <yatsenko@...a.com>, 
	Kumar Kartikeya Dwivedi <memxor@...il.com>, bpf <bpf@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	linux-trace-kernel <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: add missing __printf attributes

On Tue, Feb 3, 2026 at 9:44 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
> > On Tue, Feb 3, 2026 at 8:58 AM Arnd Bergmann <arnd@...db.de> wrote:
> >> On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
> >> > On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@...nel.org> wrote:
> >> >>
> >> >> From: Arnd Bergmann <arnd@...db.de>
> >> >>
> >> >> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
> >> >> is passed to the compiler, e.g. in 'make W=1':
> >> >>
> >> >> 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);
> >> >>       |         ^~~
> >> >>
> >> >> The attribute here is useless since there are no callers from C code,
> >> >> but it helps to shut up the output anyway so we can eventually turn
> >> >> the warning option on by default.
> >> >>
> >> >> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> >> >
> >> > This was discussed and it's incorrect.
> >>
> >> Do you have a reference to why it's incorrect?  It seems harmless
> >> and gives me a clean kernel build in combination with a handful
> >> of other fixes after enabling the option by default, but I assume
> >> I'm missing something,
> >
> > because it's not a printf format. There are no varags here.
> > gnu_printf attribute takes two arguments:
> > format (archetype, string-index, first-to-check)
> > Also
> > "GCC requires a function with the 'format' attribute to be variadic"
>
> My impression was that at least vbin_printf() falls into the
> same category as vprintf(), which is explictly mentioned in the
> gcc documentation:
>
>   For functions where the arguments are not available to be checked
>   (such as 'vprintf'), specify the third parameter as zero.

Not quite. That comment in gcc doc is somewhat misleading.
zero means that it should be va_list.

Examples of correct annotations:

static __attribute__((unused, format(printf, 2, 0)))
int vfprintf(FILE *stream, const char *fmt, va_list args)


static __attribute__((unused, format(printf, 2, 3)))
int fprintf(FILE *stream, const char *fmt, ...)

A comment in gcc sources:
      /* Functions taking a va_list normally pass a non-literal format
         string.  These functions typically are declared with
         first_arg_num == 0, ...

Currently gcc doesn't go deep into va_list to validate them,
since they're likely not compile time constants,
but that's the meaning of zero.

> I also see the comment about bstr_printf() mention that it
> uses a vsnprintf() compatible format, which would indicate that
> marking the format argument isn't wrong, though I agree it is
> not actually useful if there are no callers that pass a string
> literal.

In general I don't think it's a good idea to add nop annotations
just to shut up over eager compiler warning.