linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List <linux-mm@kvack.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [linux-next:master 13015/13783] drivers/net/virtio_net.c:4340:35: error: '%u' directive writing between 1 and 10 bytes into a region of size 9
Date: Fri, 19 Jan 2024 15:44:35 +0800	[thread overview]
Message-ID: <7f334083-afab-4393-97d5-7d5fdfab2991@linux.dev> (raw)
In-Reply-To: <202401190425.IGYMqCJW-lkp@intel.com>


在 2024/1/19 4:36, kernel test robot 写道:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   2863b714f3ad0a9686f2de1b779228ad8c7a8052
> commit: e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 [13015/13783] virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings
> config: x86_64-sof-customedconfig-avs-defconfig (https://download.01.org/0day-ci/archive/20240119/202401190425.IGYMqCJW-lkp@intel.com/config)
> compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0

I can reproduce this problem in my local host.

It seems that this problem is related with gcc-7. In the same test 
environment, with gcc-7, this problem will occur. With gcc later than 
version 9, this problem will not occur.

And with u16, the range of %u should be [0, 65535]. Not the following:
"
    drivers/net/virtio_net.c:4141:27: note: directive argument in the 
range [0, 2147483647]
       sprintf(vi->sq[i].name, "output.%u", i); "

And the size of name is 16. That is, the name string can contain 15 
bytes characters.
When the variable i is set to the maximum 65535, the string should be 
"output.65535". The size of the string is 12 + 1 = 13 bytes.
The size of the name is greater than the maximum string "output.65535".

In short, from the above, this problem results from gcc-7. It is a 
problem with gcc-7. Based on my tests with gcc-9, gcc-13, this problem 
is fixed in later gcc versions.
And the warning is a false warning to this commit.

Best Regards
Zhu Yanjun

> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240119/202401190425.IGYMqCJW-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202401190425.IGYMqCJW-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>     drivers/net/virtio_net.c: In function 'init_vqs':
>     drivers/net/virtio_net.c:4339:36: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
>        sprintf(vi->rq[i].name, "input.%u", i);
>                                         ^
>     drivers/net/virtio_net.c:4339:3: note: 'sprintf' output between 8 and 17 bytes into a destination of size 16
>        sprintf(vi->rq[i].name, "input.%u", i);
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> drivers/net/virtio_net.c:4340:35: error: '%u' directive writing between 1 and 10 bytes into a region of size 9 [-Werror=format-overflow=]
>        sprintf(vi->sq[i].name, "output.%u", i);
>                                        ^~
>     drivers/net/virtio_net.c:4340:27: note: directive argument in the range [0, 2147483647]
>        sprintf(vi->sq[i].name, "output.%u", i);
>                                ^~~~~~~~~~~
>     drivers/net/virtio_net.c:4340:3: note: 'sprintf' output between 9 and 18 bytes into a destination of size 16
>        sprintf(vi->sq[i].name, "output.%u", i);
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     cc1: all warnings being treated as errors
>
>
> vim +4340 drivers/net/virtio_net.c
>
>    4293	
>    4294	static int virtnet_find_vqs(struct virtnet_info *vi)
>    4295	{
>    4296		vq_callback_t **callbacks;
>    4297		struct virtqueue **vqs;
>    4298		const char **names;
>    4299		int ret = -ENOMEM;
>    4300		int total_vqs;
>    4301		bool *ctx;
>    4302		u16 i;
>    4303	
>    4304		/* We expect 1 RX virtqueue followed by 1 TX virtqueue, followed by
>    4305		 * possible N-1 RX/TX queue pairs used in multiqueue mode, followed by
>    4306		 * possible control vq.
>    4307		 */
>    4308		total_vqs = vi->max_queue_pairs * 2 +
>    4309			    virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ);
>    4310	
>    4311		/* Allocate space for find_vqs parameters */
>    4312		vqs = kcalloc(total_vqs, sizeof(*vqs), GFP_KERNEL);
>    4313		if (!vqs)
>    4314			goto err_vq;
>    4315		callbacks = kmalloc_array(total_vqs, sizeof(*callbacks), GFP_KERNEL);
>    4316		if (!callbacks)
>    4317			goto err_callback;
>    4318		names = kmalloc_array(total_vqs, sizeof(*names), GFP_KERNEL);
>    4319		if (!names)
>    4320			goto err_names;
>    4321		if (!vi->big_packets || vi->mergeable_rx_bufs) {
>    4322			ctx = kcalloc(total_vqs, sizeof(*ctx), GFP_KERNEL);
>    4323			if (!ctx)
>    4324				goto err_ctx;
>    4325		} else {
>    4326			ctx = NULL;
>    4327		}
>    4328	
>    4329		/* Parameters for control virtqueue, if any */
>    4330		if (vi->has_cvq) {
>    4331			callbacks[total_vqs - 1] = NULL;
>    4332			names[total_vqs - 1] = "control";
>    4333		}
>    4334	
>    4335		/* Allocate/initialize parameters for send/receive virtqueues */
>    4336		for (i = 0; i < vi->max_queue_pairs; i++) {
>    4337			callbacks[rxq2vq(i)] = skb_recv_done;
>    4338			callbacks[txq2vq(i)] = skb_xmit_done;
>    4339			sprintf(vi->rq[i].name, "input.%u", i);
>> 4340			sprintf(vi->sq[i].name, "output.%u", i);
>    4341			names[rxq2vq(i)] = vi->rq[i].name;
>    4342			names[txq2vq(i)] = vi->sq[i].name;
>    4343			if (ctx)
>    4344				ctx[rxq2vq(i)] = true;
>    4345		}
>    4346	
>    4347		ret = virtio_find_vqs_ctx(vi->vdev, total_vqs, vqs, callbacks,
>    4348					  names, ctx, NULL);
>    4349		if (ret)
>    4350			goto err_find;
>    4351	
>    4352		if (vi->has_cvq) {
>    4353			vi->cvq = vqs[total_vqs - 1];
>    4354			if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VLAN))
>    4355				vi->dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
>    4356		}
>    4357	
>    4358		for (i = 0; i < vi->max_queue_pairs; i++) {
>    4359			vi->rq[i].vq = vqs[rxq2vq(i)];
>    4360			vi->rq[i].min_buf_len = mergeable_min_buf_len(vi, vi->rq[i].vq);
>    4361			vi->sq[i].vq = vqs[txq2vq(i)];
>    4362		}
>    4363	
>    4364		/* run here: ret == 0. */
>    4365	
>    4366	
>    4367	err_find:
>    4368		kfree(ctx);
>    4369	err_ctx:
>    4370		kfree(names);
>    4371	err_names:
>    4372		kfree(callbacks);
>    4373	err_callback:
>    4374		kfree(vqs);
>    4375	err_vq:
>    4376		return ret;
>    4377	}
>    4378	
>


  reply	other threads:[~2024-01-19  7:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 20:36 kernel test robot
2024-01-19  7:44 ` Zhu Yanjun [this message]
2024-01-24  6:43   ` Yujie Liu

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=7f334083-afab-4393-97d5-7d5fdfab2991@linux.dev \
    --to=yanjun.zhu@linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@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