From: Petr Mladek <pmladek@suse.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Down <chris@chrisdown.name>,
oe-kbuild-all@lists.linux.dev, kernel test robot <lkp@intel.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] scsi: core: Safe warning about bad dev info string
Date: Fri, 12 Jan 2024 12:27:17 +0100 [thread overview]
Message-ID: <ZaEiFXscVBdOJEeI@alley> (raw)
In-Reply-To: <CAMuHMdW1XyimybybSwAfwgzeUyFj6riRZZZzQK7zjTVUJziX-Q@mail.gmail.com>
On Fri 2024-01-12 10:22:44, Geert Uytterhoeven wrote:
> Hi Petr,
>
> On Thu, Jan 11, 2024 at 5:26 PM Petr Mladek <pmladek@suse.com> wrote:
> > Both "model" and "strflags" are passed to "%s" even when one or both
> > are NULL.
> >
> > It is safe because vsprintf() would detect the NULL pointer and print
> > "(null)". But it is a kernel-specific feature and compiler warns
> > about it:
> >
> > <warning>
> > In file included from include/linux/kernel.h:19,
> > from arch/x86/include/asm/percpu.h:27,
> > from arch/x86/include/asm/current.h:6,
> > from include/linux/sched.h:12,
> > from include/linux/blkdev.h:5,
> > from drivers/scsi/scsi_devinfo.c:3:
> > drivers/scsi/scsi_devinfo.c: In function 'scsi_dev_info_list_add_str':
> > >> include/linux/printk.h:434:44: warning: '%s' directive argument is null [-Wformat-overflow=]
> > 434 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > | ^
> > include/linux/printk.h:430:3: note: in definition of macro 'printk_index_wrap'
> > 430 | _p_func(_fmt, ##__VA_ARGS__); \
> > | ^~~~~~~
> > drivers/scsi/scsi_devinfo.c:551:4: note: in expansion of macro 'printk'
> > 551 | printk(KERN_ERR "%s: bad dev info string '%s' '%s'"
> > | ^~~~~~
> > drivers/scsi/scsi_devinfo.c:552:14: note: format string is defined here
> > 552 | " '%s'\n", __func__, vendor, model,
> > | ^~
> > </warning>
> >
> > Do not rely on the kernel specific behavior and print the message
> > a safe way.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202401112002.AOjwMNM0-lkp@intel.com/
> > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > ---
> > Note: The patch is only compile tested.
> >
> > drivers/scsi/scsi_devinfo.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
> > index 3fcaf10a9dfe..ba7237e83863 100644
> > --- a/drivers/scsi/scsi_devinfo.c
> > +++ b/drivers/scsi/scsi_devinfo.c
> > @@ -551,9 +551,9 @@ static int scsi_dev_info_list_add_str(char *dev_list)
> > if (model)
> > strflags = strsep(&next, next_check);
> > if (!model || !strflags) {
> > - printk(KERN_ERR "%s: bad dev info string '%s' '%s'"
> > - " '%s'\n", __func__, vendor, model,
> > - strflags);
> > + pr_err("%s: bad dev info string '%s' '%s' '%s'\n",
> > + __func__, vendor, model ? model : "",
> > + strflags ? strflags : "");
>
> Do we really want to make this change?
> The kernel's vsprintf() implementation has supported NULL pointers
> since forever, and lots of code relies on that behavior.
Yeah, it was safe even in the first git commit. And it was probably
safe long before.
Well, I can't find easily how much code relies on this. I would
personally do not rely on it when writing new code.
> Perhaps this warning can be disabled instead?
IMHO, it is not a good idea to disable the warning. I believe that it
checks also other scenarios and can find real problems.
Also I think that compilers are getting more and more "clever".
So keeping the "suspicious" code might be fighting with windmills.
Best Regards,
Petr
next prev parent reply other threads:[~2024-01-12 11:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 16:24 [PATCH] scsi: core: Safe warning about bad dev info string Petr Mladek
2024-01-11 17:55 ` Bart Van Assche
2024-01-12 9:22 ` Geert Uytterhoeven
2024-01-12 11:27 ` Petr Mladek [this message]
2024-01-12 11:33 ` Geert Uytterhoeven
2024-01-16 19:36 ` Chris Down
2024-01-30 2:27 ` Martin K. Petersen
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=ZaEiFXscVBdOJEeI@alley \
--to=pmladek@suse.com \
--cc=arnd@arndb.de \
--cc=chris@chrisdown.name \
--cc=geert@linux-m68k.org \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkp@intel.com \
--cc=martin.petersen@oracle.com \
--cc=oe-kbuild-all@lists.linux.dev \
/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.