From: Edward Cree <ecree.xilinx@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Nathan Chancellor <nathan@kernel.org>,
Jeff Garzik <jgarzik@redhat.com>,
Ben Hutchings <bhutchings@solarflare.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Brett Creeley <brett.creeley@amd.com>,
Breno Leitao <leitao@debian.org>, Kees Cook <kees@kernel.org>,
netdev@vger.kernel.org, linux-net-drivers@amd.com,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] net: sfc: avoid format string warning
Date: Fri, 20 Mar 2026 19:04:33 +0000 [thread overview]
Message-ID: <90a03d3c-def3-4e34-89a0-6e952d3b0d7a@gmail.com> (raw)
In-Reply-To: <20260320151924.3474821-1-arnd@kernel.org>
On 20/03/2026 15:19, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Three sfc drivers contain the same *_fill_test() function that takes
> a format string argument that gets passed down to snprintf(), producing
> a warning with clang-22:
>
> drivers/net/ethernet/sfc/falcon/ethtool.c:227:60: error: diagnostic behavior may be improved by adding
> the 'format(printf, 7, 8)' attribute to the declaration of 'ef4_fill_test' [-Werror,-Wmissing-format-attribute]
> 210 | snprintf(test_str, sizeof(test_str), test_format, test_id);
> | ^
> drivers/net/ethernet/sfc/falcon/ethtool.c:210:13: note: 'ef4_fill_test' declared here
>
> Rework these to take a varargs based test_format that allows better
> type checking and avoids this warning.
>
> Fixes: 3273c2e8c66a ("[netdrvr] sfc: sfc: Add self-test support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I'm not convinced this is an improvement. The function takes *two* printf
format strings (unit_format and test_format), and this only annotates and
varargs-ifies one of them (and doesn't harden the unit_format, which has
the considerably more worrying-looking "if it has a % in, assume it takes
precisely one int argument").
So it may make things 'look' hardened enough to satisfy the compiler
warning, but that just hides the unsafety and might sucker future
developers into thinking "oh, the compiler knows about the format strings
so I don't need to check it by hand".
I'm not sure what a proper fix would look like — possibly a rewrite adding
a separate efx_fill_test_perq() function for the cases with a nontrivial
unit_format, baking in the knowledge that the format is always "foo%d"
for some constant string foo and thus we don't actually need to pass in
an arbitrary format string.
> -static void efx_fill_test(unsigned int test_index, u8 *strings, u64 *data,
> - int *test, const char *unit_format, int unit_id,
> - const char *test_format, const char *test_id)
> +static void __printf(7, 8)
> +efx_fill_test(unsigned int test_index, u8 *strings, u64 *data,
I don't like splitting the specifiers/return type from the function name
like this. It's not Linux style[1].
(From a quick poke around the tree, there seems to be less consensus on
where the __printf attribute goes — some put it on its own line before
`static`, some would put it between `static` and `void`… sigh.)
-Ed
[1]: https://lore.kernel.org/all/1054519757.161606@palladium.transmeta.com/T/#u
next prev parent reply other threads:[~2026-03-20 19:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 15:19 [PATCH] net: sfc: avoid format string warning Arnd Bergmann
2026-03-20 18:00 ` Kees Cook
2026-03-20 19:04 ` Edward Cree [this message]
2026-03-20 20:48 ` Arnd Bergmann
2026-03-25 0:22 ` Edward Cree
2026-03-25 13:48 ` Arnd Bergmann
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=90a03d3c-def3-4e34-89a0-6e952d3b0d7a@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=bhutchings@solarflare.com \
--cc=brett.creeley@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jgarzik@redhat.com \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=pabeni@redhat.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