From: Salvatore Bonaccorso <carnil@debian.org>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: Michel Lind <michel@michel-slm.name>,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH ethtool] netlink: fix print_string when the value is NULL
Date: Mon, 11 Aug 2025 22:23:38 +0200 [thread overview]
Message-ID: <aJpRSuCpo37TCLZZ@eldamar.lan> (raw)
In-Reply-To: <b6unuycjddzrl55q3gwtki2rmm2ituknbmgwpuorgten5xr65w@w4dnhvf6mkoa>
Hi,
On Mon, Aug 11, 2025 at 10:07:00PM +0200, Michal Kubecek wrote:
> Dne Sun, Aug 10, 2025 at 09:14:26AM GMT, Salvatore Bonaccorso napsal:
> > Hi Michal,
> >
> > On Fri, Aug 08, 2025 at 01:05:52AM +0200, Michal Kubecek wrote:
> > > On Thu, Jul 24, 2025 at 07:48:11PM GMT, Michel Lind wrote:
> > > > The previous fix in commit b70c92866102 ("netlink: fix missing headers
> > > > in text output") handles the case when value is NULL by still using
> > > > `fprintf` but passing no value.
> > > >
> > > > This fails if `-Werror=format-security` is passed to gcc, as is the
> > > > default in distros like Fedora.
> > > >
> > > > ```
> > > > json_print.c: In function 'print_string':
> > > > json_print.c:147:25: error: format not a string literal and no format arguments [-Werror=format-security]
> > > > 147 | fprintf(stdout, fmt);
> > > > |
> > > > ```
> > > >
> > > > Use `fprintf(stdout, "%s", fmt)` instead, using the format string as the
> > > > value, since in this case we know it is just a string without format
> > > > chracters.
> > > >
> > > > Reviewed-by: Jakub Kicinski <kuba@kernel.org>
> > > > Signed-off-by: Michel Lind <michel@michel-slm.name>
> > >
> > > Applied, thank you.
> > >
> > > It's a bit surprising that I didn't hit this problem as I always test
> > > building with "-Wall -Wextra -Werror". I suppose this option is not
> > > contained in -Wall or -Wextra.
> > >
> > > Michal
> > >
> > > > ---
> > > > json_print.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/json_print.c b/json_print.c
> > > > index e07c651..75e6cd9 100644
> > > > --- a/json_print.c
> > > > +++ b/json_print.c
> > > > @@ -144,7 +144,7 @@ void print_string(enum output_type type,
> > > > if (value)
> > > > fprintf(stdout, fmt, value);
> > > > else
> > > > - fprintf(stdout, fmt);
> > > > + fprintf(stdout, "%s", fmt);
> > > > }
> > > > }
> > > >
> > > > --
> > > > 2.50.1
> >
> > As b70c92866102 ("netlink: fix missing headers in text output") was
> > backported as well for the 6.14.2 version, should that get as well a
> > new release 6.14.3 with the fix?
>
> I could do that but it didn't seem necessary. If I understand correctly,
> this patch does not address any runtime issue (at least not until there
> is an actual call of print_string() with null value and fmt containing
> a template); and the build issue only happens with a very specific
> compiler option which is not only not default but is not included even
> in "-Wall -Wextra" (not even in gcc15).
>
> I'm aware that the commit message says that Fedora uses that compiler
> option in its package builds but that's something that can be addressed
> by a distribution patch. Therefore my plan was to cherry pick the commit
> into ethtool-6.14.y branch but not to release 6.14.3 unless something
> more serious shows up.
>
> But if I misunderstood the situation and 6.14.3 with this commit would
> be really helpful, I can reconsider.
No not urgent, but I hit the same issue when preparing 6.14.2 for
Debian trixie. But I can equally just cherry-pick the commit locally
and then drop it once 6.14.3 is released.
So really no hurry about that.
Regards,
Salvatore
next prev parent reply other threads:[~2025-08-11 20:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 0:48 [PATCH ethtool] netlink: fix print_string when the value is NULL Michel Lind
2025-08-07 23:05 ` Michal Kubecek
2025-08-10 7:14 ` Salvatore Bonaccorso
2025-08-11 20:07 ` Michal Kubecek
2025-08-11 20:23 ` Salvatore Bonaccorso [this message]
2025-08-12 6:14 ` Michal Kubecek
2025-08-07 23:49 ` 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=aJpRSuCpo37TCLZZ@eldamar.lan \
--to=carnil@debian.org \
--cc=kuba@kernel.org \
--cc=michel@michel-slm.name \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.