All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: wangyunjian <wangyunjian@huawei.com>
Cc: "huawei.xie@intel.com" <huawei.xie@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: A question about the function fill_vec_buf
Date: Mon, 16 Jan 2017 15:04:25 +0800	[thread overview]
Message-ID: <20170116070425.GM9770@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <34EFBCA9F01B0748BEB6B629CE643AE60BA9405D@DGGEMA505-MBX.china.huawei.com>

On Fri, Jan 13, 2017 at 10:20:55AM +0000, wangyunjian wrote:
> In function fill_vec_buf, it will happen uint32_t cast to uint16_t, when the
> *desc_chain_len is assigned by the len.
> 
> This maybe result in data truncation.

Do you have a real example?

I don't think data truncation could happen here (when this piece of code
just handles virtio-net part): a packet length could not exceed 64K.

	--yliu
> 
>  
> 
> static inline int __attribute__((always_inline))
> 
> fill_vec_buf(struct virtio_net *dev, struct vhost_virtqueue *vq,
> 
>                                                 uint32_t avail_idx, uint32_t
> *vec_idx,
> 
>                                                 struct buf_vector *buf_vec,
> uint16_t *desc_chain_head,
> 
>                                                 uint16_t *desc_chain_len)
>                                                                         --The
> desc_chain_len is defined uint16_t.
> 
> {
> 
>                 uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
> 
>                 uint32_t vec_id = *vec_idx;
> 
>                 uint32_t len    = 0;
>                                                                                                                           
> --The len is defined uint32_t.
> 
>                 struct vring_desc *descs = vq->desc;
> 
>  
> 
>                 *desc_chain_head = idx;
> 
>                 …
> 
>  
> 
>                 while (1) {
> 
>                                 if (unlikely(vec_id >= BUF_VECTOR_MAX || idx >=
> vq->size))
> 
>                                                 return -1;
> 
>  
> 
>                                 len += descs[idx].len; 
> 
>                                 buf_vec[vec_id].buf_addr = descs[idx].addr;
> 
>                                 buf_vec[vec_id].buf_len  = descs[idx].len;
> 
>                                 buf_vec[vec_id].desc_idx = idx;
> 
>                                 vec_id++;
> 
>  
> 
>                                 if ((descs[idx].flags & VRING_DESC_F_NEXT) ==
> 0)
> 
>                                                 break;
> 
>  
> 
>                                 idx = descs[idx].next;
> 
>                 }
> 
>  
> 
>                 *desc_chain_len = len;
>                                                       
>                                                       --Here, uint32_t cast to
> uint16_t.
> 
>                 *vec_idx = vec_id;
> 
>  
> 
>                 return 0;
> 
> }
> 

      reply	other threads:[~2017-01-16  7:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13 10:20 A question about the function fill_vec_buf wangyunjian
2017-01-16  7:04 ` Yuanhan Liu [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=20170116070425.GM9770@yliu-dev.sh.intel.com \
    --to=yuanhan.liu@linux.intel.com \
    --cc=dev@dpdk.org \
    --cc=huawei.xie@intel.com \
    --cc=wangyunjian@huawei.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 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.