DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, cheng1.jiang@intel.com, chenbo.xia@intel.com,
	zhoumin@loongson.cn, stable@dpdk.org,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH] vhost: fix compilation issue in async path
Date: Wed, 5 Oct 2022 17:09:18 +0200	[thread overview]
Message-ID: <61f1cd33-e5ee-382c-1b8b-814c84b22c6b@redhat.com> (raw)
In-Reply-To: <CAJFAV8ybX6xCuecz9Qjy9d4y5ZXghnBpZ0TVdB33G_r9j2iA-Q@mail.gmail.com>



On 10/5/22 16:56, David Marchand wrote:
> On Wed, Oct 5, 2022 at 4:49 PM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>>
>> This patch fixes a compilation issue met with GCC on
> 
> GCC 12 (it is worth detailing, since I and Thomas hit the same issue
> on some other cross compiling toolchains using GCC 12).
> 
>> Loongarch64:
> 
> LoongArch64
> 

Oops, I did the changes you asked me off-list, but forgot to format
the patch again!

Posting v2.

>>
>> In function ‘mbuf_to_desc’,
>>      inlined from ‘vhost_enqueue_async_packed’ at ../../../dpdk/lib/vhost/virtio_net.c:1822:6,
>>      inlined from ‘virtio_dev_rx_async_packed’ at ../../../dpdk/lib/vhost/virtio_net.c:1836:6,
>>      inlined from ‘virtio_dev_rx_async_submit_packed’ at ../../../dpdk/lib/vhost/virtio_net.c:1895:7:
>> ../../../dpdk/lib/vhost/virtio_net.c:1159:18: error: ‘buf_vec[0].buf_addr’ may be used uninitialized [-Werror=maybe-uninitialized]
>>   1159 |         buf_addr = buf_vec[vec_idx].buf_addr;
>>        |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ../../../dpdk/lib/vhost/virtio_net.c: In function ‘virtio_dev_rx_async_submit_packed’:
>> ../../../dpdk/lib/vhost/virtio_net.c:1834:27: note: ‘buf_vec’ declared here
>>   1834 |         struct buf_vector buf_vec[BUF_VECTOR_MAX];
>>        |                           ^~~~~~~
>>
>> It happens because the compiler assumes that 'size'
>> variable in vhost_enqueue_async_packed could wrap to 0 since
>> 'size' is uint32_t and pkt->pkt_len too.
>>
>> In practice, it would never happen since 'pkt->pkt_len' is
>> unlikely to be close to UINT32_MAX, but let's just change
>> 'size' to uint64_t to make the compiler happy without
>> having to add runtime checks.
>>
>> Fixes: 873e8dad6f49 ("vhost: support packed ring in async datapath")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
> 
> 


      reply	other threads:[~2022-10-05 15:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 14:48 Maxime Coquelin
2022-10-05 14:56 ` David Marchand
2022-10-05 15:09   ` Maxime Coquelin [this message]

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=61f1cd33-e5ee-382c-1b8b-814c84b22c6b@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=chenbo.xia@intel.com \
    --cc=cheng1.jiang@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=zhoumin@loongson.cn \
    /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;
as well as URLs for NNTP newsgroup(s).