From: David Laight <David.Laight@ACULAB.COM>
To: 'Stefan Hajnoczi' <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
Jason Wang <jasowang@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Suwan Kim <suwan.kim027@gmail.com>,
kernel test robot <lkp@intel.com>
Subject: RE: [PATCH] virtio_blk: fix snprintf truncation compiler warning
Date: Tue, 5 Dec 2023 13:51:39 +0000 [thread overview]
Message-ID: <1c1d57ba13c2497f99e5e0a9c5954667@AcuMS.aculab.com> (raw)
In-Reply-To: <20231204140743.1487843-1-stefanha@redhat.com>
From: Stefan Hajnoczi
> Sent: 04 December 2023 14:08
>
> Commit 4e0400525691 ("virtio-blk: support polling I/O") triggers the
> following gcc 13 W=1 warnings:
>
> drivers/block/virtio_blk.c: In function ‘init_vq’:
> drivers/block/virtio_blk.c:1077:68: warning: ‘%d’ directive output may be truncated writing between 1
> and 11 bytes into a region of size 7 [-Wformat-truncation=]
> 1077 | snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
> | ^~
> drivers/block/virtio_blk.c:1077:58: note: directive argument in the range [-2147483648, 65534]
> 1077 | snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
> | ^~~~~~~~~~~~~
> drivers/block/virtio_blk.c:1077:17: note: ‘snprintf’ output between 11 and 21 bytes into a destination
> of size 16
> 1077 | snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This is a false positive because the lower bound -2147483648 is
> incorrect. The true range of i is [0, num_vqs - 1] where 0 < num_vqs <
> 65536.
>
> The code mixes int, unsigned short, and unsigned int types in addition
> to using "%d" for an unsigned value. Use unsigned short and "%u"
> consistently to solve the compiler warning.
>
> Cc: Suwan Kim <suwan.kim027@gmail.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312041509.DIyvEt9h-lkp@intel.com/
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> drivers/block/virtio_blk.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index d53d6aa8ee69..47556d8ccc32 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -1019,12 +1019,12 @@ static void virtblk_config_changed(struct virtio_device *vdev)
> static int init_vq(struct virtio_blk *vblk)
> {
> int err;
> - int i;
> + unsigned short i;
> vq_callback_t **callbacks;
> const char **names;
> struct virtqueue **vqs;
> unsigned short num_vqs;
> - unsigned int num_poll_vqs;
> + unsigned short num_poll_vqs;
> struct virtio_device *vdev = vblk->vdev;
> struct irq_affinity desc = { 0, };
>
> @@ -1068,13 +1068,13 @@ static int init_vq(struct virtio_blk *vblk)
>
> for (i = 0; i < num_vqs - num_poll_vqs; i++) {
Ugg doing arithmetic on char/short is likely to generate horrid
code (especially on non-x86).
Hint, there will be explicit masking and/or sign/zero extension.
Even the array index might add extra code (although there'll be
an explicit sign extend to 64bit with the current code).
There really ought to be a better way to make gcc STFU.
In this case 'unsigned int i' might be enough since gcc seems
to have a small enough upper bound.
David
> callbacks[i] = virtblk_done;
> - snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req.%d", i);
> + snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req.%u", i);
> names[i] = vblk->vqs[i].name;
> }
>
> for (; i < num_vqs; i++) {
> callbacks[i] = NULL;
> - snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%d", i);
> + snprintf(vblk->vqs[i].name, VQ_NAME_LEN, "req_poll.%u", i);
> names[i] = vblk->vqs[i].name;
> }
>
> --
> 2.43.0
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-12-05 13:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 14:07 Stefan Hajnoczi
2023-12-05 6:59 ` Chaitanya Kulkarni
2023-12-05 13:51 ` David Laight [this message]
2023-12-05 14:19 ` Stefan Hajnoczi
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=1c1d57ba13c2497f99e5e0a9c5954667@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=axboe@kernel.dk \
--cc=jasowang@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=suwan.kim027@gmail.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.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
all inboxes | Powered by JetHome®