From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 8CB661B519 for ; Thu, 4 Oct 2018 17:09:37 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20181004150937euoutp029578f01e6758b51c88e9966b01da6d2d~acF9Q5HTO2702427024euoutp02a for ; Thu, 4 Oct 2018 15:09:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20181004150937euoutp029578f01e6758b51c88e9966b01da6d2d~acF9Q5HTO2702427024euoutp02a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1538665777; bh=pmR6bPzREpPahygo/J09FnVDBkyDT/Ipg2YKdombrTE=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=quBAxXedicxKEsBOEvyTeGE3MhSepRinz+7UBBNvNx0xR8AtX14VIItrYXUSnf12V LkMW4eshBeXrQRpo8dbLdXtaFz8gjP96tDzFzhw9J1o24KOr6qP208CB+SAT4jstid YxTe58QgOqMoq/jZ9+0jxwrcSufVTdE8VQpXDh70= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20181004150936eucas1p159e382446170e2c76ee93ef5f0c4dbf6~acF8sSggd0572505725eucas1p1m; Thu, 4 Oct 2018 15:09:36 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 5F.6D.04441.03D26BB5; Thu, 4 Oct 2018 16:09:36 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20181004150935eucas1p1dbb293daf4c6ba77e8d90e01602fa476~acF70-oX70310403104eucas1p17; Thu, 4 Oct 2018 15:09:35 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20181004150935eusmtrp14b5b1abdc1352c1a8087ec348c9e07b0~acF7j7JSO3105431054eusmtrp1D; Thu, 4 Oct 2018 15:09:35 +0000 (GMT) X-AuditID: cbfec7f2-5e3ff70000001159-ae-5bb62d301e57 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id A7.E9.04284.F2D26BB5; Thu, 4 Oct 2018 16:09:35 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20181004150934eusmtip17b5ce53c05a523190ec167e7315bbaf1~acF63bo4q0712507125eusmtip1c; Thu, 4 Oct 2018 15:09:34 +0000 (GMT) To: Maxime Coquelin , dev@dpdk.org, tiwei.bie@intel.com, zhihong.wang@intel.com, jfreimann@redhat.com, nicknickolaev@gmail.com, bruce.richardson@intel.com, alejandro.lucero@netronome.com Cc: dgilbert@redhat.com, stable@dpdk.org From: Ilya Maximets Date: Thu, 4 Oct 2018 18:11:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9eade352-c26c-f8db-8a6e-b6b81a54c374@redhat.com> Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRzGec852zlON95Na//ULJaURt4o6nyIVhK0T13UIBpRSw+6clN2 1LQ+uC7kMrstyloXkvCSGVLq0ooyM83MWbHFnJaJBmUXcZphluY8RX77vf/nfZ7/+8DLkIpG UTCjN2ZxJqMuXSWWUPaWcUdUbJRdG1vRr2Qd3jKCdVeq2W/euwR7wv6OZp0F4zTrqCql2JZj Dyi2veQNxU5aftFsnXmKYGteWYm1/pqf10pFmgbbW1pz/cEnQlN8vI/UDD10iTUnayvRZvF2 yeoULl2fw5li1uySpF12XyIyvfLcqw0XkRl1yQqRHwN4Bdx2dIsKkYRR4AoEnS672Cco8CiC 8vOrBB5BYPUc+Geoe9FICIZyBJ6SL2LhMIygrdoi8t0KxFuhseL8jBCEexA4S1/PxJI4Aqpd A8jHYrwMnt9snmEKh8Pv4jHax3PwNmh+XzIzl2I5tF0coAoRw/jhNVBTJBFilHBo9IZI4AVw uO4S6dsF+A0Nnpqyv94cuHKuV+zzAl4PL12RQoNAGGytpQUOhfazRZTA+dB75BMSciwIipsm CUFQQ+1nB+3LIXEkVN+LESLXwalb8QLKwP1VLrxGBlZ7MSmMpWA5qhAywmHicTkpcDB0fRuh TyOVbVZF26xetlm9bP/XXkNUJVJy2bwhlePjjNy+aF5n4LONqdHJGYY7aPpftU+2euvR99e7 mxBmkCpA+nGRXasQ6XL4PEMTAoZUBUm7I6ZH0hRd3n7OlLHTlJ3O8U0ohKFUSmnZ1dtaBU7V ZXF7OS6TM/1TCcYv2IxyHdFLniTsGErKUTvOTljmedrDN38u2nhfPu/DYBi5wWZevrI/1mZ5 unBhD3bIOrbISxbHPto0+rBzLEZrTrzwzBnSoSUm5MNt4RlTVWWDP/bw+sRzNk9o1X7nz/xR V1K8W6pOKBjKT0Z1UzetB87MX209GNaQ4OzjlugD6v3nqig+TRe3lDTxuj/LBd1vUwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsVy+t/xu7r6utuiDW4vlbY492kZk8WNVfYW 7z5tZ7Lo3XaP3eJK+092i3NrlrJYHOvcw2JxeuE1Fot/HX/YLbY2/Gey2HxxEpMDt8evBUtZ PXbOusvusXjPSyaP6d0PmT3e77vK5tG3ZRVjAFuUnk1RfmlJqkJGfnGJrVK0oYWRnqGlhZ6R iaWeobF5rJWRqZK+nU1Kak5mWWqRvl2CXsacG7OZCj4JVszbOZOxgfEmXxcjJ4eEgInE1jMH mLoYuTiEBJYySvzqecEIkZCS+PHrAiuELSzx51oXG0TRe0aJ9UcOs4AkhAVCJQ6smAaWEBG4 wyixZdYZsG5mAQ2J9VefMEJ0vGCSuPWnkRkkwSagI3Fq9RGwIl4BO4ntP2aBTWIRUJH4O/0b O4gtKhAhsXr5C1aIGkGJkzOfANVwcHAC1W/u4YKYry7xZ94lZghbXKLpy0pWCFteonnrbOYJ jEKzkHTPQtIyC0nLLCQtCxhZVjGKpJYW56bnFhvqFSfmFpfmpesl5+duYgRG6rZjPzfvYLy0 MfgQowAHoxIP7wvlbdFCrIllxZW5hxglOJiVRHhvawCFeFMSK6tSi/Lji0pzUosPMZoC/TaR WUo0OR+YRPJK4g1NDc0tLA3Njc2NzSyUxHnPG1RGCQmkJ5akZqemFqQWwfQxcXBKNTCyX7U1 sX912Xm2aGT+sp57cj5Hl+88tUzqjUXM1s74Lf27wrU05c4fNjvVfm6KbfSUXapaOpzdUs2n Xs48eP7pSc3Jp4x2tV+JeuxjvVhz09Otmvqyn/flKdzPnvQ8+ND+fxc3eEnmL110vqX+gKVX UJCIa450p1bJkan6PeL585/9Wr3y6WsOJZbijERDLeai4kQAADx1PeoCAAA= Message-Id: <20181004150935eucas1p1dbb293daf4c6ba77e8d90e01602fa476~acF70-oX70310403104eucas1p17@eucas1p1.samsung.com> X-CMS-MailID: 20181004150935eucas1p1dbb293daf4c6ba77e8d90e01602fa476 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20181004081447epcas2p25e5251e517f9f2a465106cb0681b16f7 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20181004081447epcas2p25e5251e517f9f2a465106cb0681b16f7 References: <20181004081403.8039-1-maxime.coquelin@redhat.com> <20181004081403.8039-6-maxime.coquelin@redhat.com> <20181004145646eucas1p11bcd0adb05bc38ff89e19c60b5af0734~ab6vFE4Uy0940809408eucas1p15@eucas1p1.samsung.com> <9eade352-c26c-f8db-8a6e-b6b81a54c374@redhat.com> Subject: Re: [dpdk-dev] [PATCH v3 05/19] vhost: fix error handling when mem table gets updated 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: Thu, 04 Oct 2018 15:09:37 -0000 On 04.10.2018 18:06, Maxime Coquelin wrote: > > > On 10/04/2018 04:59 PM, Ilya Maximets wrote: >> On 04.10.2018 11:13, Maxime Coquelin wrote: >>> When the memory table gets updated, the rings addresses need >>> to be translated again. If it fails, we need to exit cleanly >>> by unmapping memory regions. >>> >>> Fixes: d5022533c20a ("vhost: retranslate vring addr when memory table changes") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Maxime Coquelin >>> --- >> >> Acked-by: Ilya Maximets >> >> Minor comments inline. >> >>>   lib/librte_vhost/vhost_user.c | 3 ++- >>>   1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c >>> index 8ffe5aa66..b6eae8dc5 100644 >>> --- a/lib/librte_vhost/vhost_user.c >>> +++ b/lib/librte_vhost/vhost_user.c >>> @@ -964,7 +964,8 @@ vhost_user_set_mem_table(struct virtio_net **pdev, struct VhostUserMsg *msg) >>>                 dev = translate_ring_addresses(dev, i); >>>               if (!dev) >>> -                return VH_RESULT_ERR; >>> +                goto err_mmap; >>> + >> >> 1. No need to have two empty lines. (You could fix this while applying) > > Right. I will either fix it while applying, or it will be in next > revision, if any. > >> 2. In current code, error on message handling will cause disconnect and >>     memory regions will be freed anyway. So, the change is not very >>     important for master (maybe just for consistency with surrounding >>     code) but it could be important for stable versions. > > I may not disconnect directly, as if reply-ack feature is negotiated[0], > the slave would reply with a NACK and function handler will return 0. > I guess that in that case the master (QEMU) will disconnect anyway, but > this is just an assumption from slave point of view. Yes, you're right. Thanks. > > [0]: REPLY_ACK protocol feature is only advertised when IOMMU support is > requested because of a bug in an old upstream QEMU version. > > Thanks! > Maxime > >>>                 *pdev = dev; >>>           } >>> > >