From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 4582A1E34 for ; Wed, 27 Feb 2019 02:52:40 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2019 17:52:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,417,1544515200"; d="scan'208";a="125483789" Received: from dpdk-tbie.sh.intel.com ([10.67.104.173]) by fmsmga007.fm.intel.com with ESMTP; 26 Feb 2019 17:52:37 -0800 Date: Wed, 27 Feb 2019 09:52:37 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: zhihong.wang@intel.com, dev@dpdk.org Message-ID: <20190227015237.GA21333@dpdk-tbie.sh.intel.com> References: <20190222024209.30879-1-tiwei.bie@intel.com> <0ee272f4-ab82-b1b9-2735-434c2d40d229@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0ee272f4-ab82-b1b9-2735-434c2d40d229@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH 0/4] Some fixes for vhost zero copy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 01:52:40 -0000 On Tue, Feb 26, 2019 at 03:46:41PM +0100, Maxime Coquelin wrote: > On 2/22/19 3:42 AM, Tiwei Bie wrote: > > Tiwei Bie (4): > > vhost: restore mbuf first when freeing zmbuf > > vhost: fix potential use-after-free for zero copy mbuf > > vhost: fix potential use-after-free for memory region > > doc: improve vhost zero copy guide > > > > doc/guides/prog_guide/vhost_lib.rst | 3 +++ > > lib/librte_vhost/vhost.h | 34 +++++++++++++++++++++++ > > lib/librte_vhost/vhost_user.c | 42 ++++++++++++++++++++++------- > > lib/librte_vhost/virtio_net.c | 34 ----------------------- > > 4 files changed, 70 insertions(+), 43 deletions(-) > > > > Looking at the spec, I think we may need also to drain zmbufs in the > VHOST_USER_SET_VRING_ENABLE for the disable case: > > "" > If VHOST_USER_F_PROTOCOL_FEATURES has been negotiated, the ring is > initialized > in a disabled state. Client must not pass data to/from the backend until > ring is enabled by > VHOST_USER_SET_VRING_ENABLE with parameter 1, or after it has been disabled > by > VHOST_USER_SET_VRING_ENABLE with parameter 0. > > Each ring is initialized in a stopped state, client must not process it > until > ring is started, or *after it has been stopped*. > "" > > Do you take care of this or I send a patch on top? Agree. Please feel free to send any patch on top. Thanks! Tiwei > > Thanks, > Maxime