From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by dpdk.org (Postfix) with ESMTP id 5CE065A79 for ; Mon, 23 May 2016 13:04:44 +0200 (CEST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O7M008U9MRU1U60@mailout3.w1.samsung.com> for dev@dpdk.org; Mon, 23 May 2016 12:04:42 +0100 (BST) X-AuditID: cbfec7f5-f792a6d000001302-21-5742e3c9b25f Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 96.9A.04866.9C3E2475; Mon, 23 May 2016 12:04:41 +0100 (BST) Received: from [106.109.129.180] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O7M00BYSMRMA7B0@eusync2.samsung.com>; Mon, 23 May 2016 12:04:41 +0100 (BST) To: Yuanhan Liu References: <1463748604-27251-1-git-send-email-i.maximets@samsung.com> <20160523105726.GI5641@yliu-dev.sh.intel.com> Cc: dev@dpdk.org, Huawei Xie , Dyasly Sergey , Heetae Ahn , Jianfeng Tan From: Ilya Maximets Message-id: <5742E3C2.9090309@samsung.com> Date: Mon, 23 May 2016 14:04:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: <20160523105726.GI5641@yliu-dev.sh.intel.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsVy+t/xK7onHzuFG3Q1aVm8+7SdyWLa59vs Fu0zzzJZXGn/yW7RPfsLm8Xk2VIW1ydcYHVg9/i1YCmrx+I9L5k85p0M9OjbsooxgCWKyyYl NSezLLVI3y6BK6P3Ym3BMemK5ztfsjcwbhHtYuTkkBAwkbg28SsLhC0mceHeerYuRi4OIYGl jBJ3D3YyQjgvGCVmH+plB6kSFnCWmHC2jxHEFhHQlXg6Zx0riC0kUCZxtGUzC0gDs8BqoO7X q8DGsgnoSJxafQSogYODV0BL4vhzsM0sAqoSx6Y8YgOxRQUiJA53doHN5xUQlPgx+R5YK6eA lcTy9gcsIK3MAnoS9y9qgYSZBeQlNq95yzyBUWAWko5ZCFWzkFQtYGRexSiaWppcUJyUnmuk V5yYW1yal66XnJ+7iRES1F93MC49ZnWIUYCDUYmHl4PFKVyINbGsuDL3EKMEB7OSCK/xI6AQ b0piZVVqUX58UWlOavEhRmkOFiVx3pm73ocICaQnlqRmp6YWpBbBZJk4OKUaGF0WHijbNKlK Zd8bqQemEfwcF94J7z+jfThg/aMd682kar7oyX57e1J0x88FyikTD26+Y2t3V+vqvvJ7sxfM u2o7ab785CkW8rsPiD9RU7hxZKXPY44rzY+apX/OuOjSdvbS+ulr+Ofd3/Bt4eL3vzd4puZ0 ftxgVun8ML2l0aa3ZNIXizl8odlTlFiKMxINtZiLihMByCZscmYCAAA= Subject: Re: [dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:04:44 -0000 On 23.05.2016 13:57, Yuanhan Liu wrote: > On Fri, May 20, 2016 at 03:50:04PM +0300, Ilya Maximets wrote: >> In current implementation guest application can reinitialize vrings >> by executing start after stop. In the same time host application >> can still poll virtqueue while device stopped in guest and it will >> crash with segmentation fault while vring reinitialization because >> of dereferencing of bad descriptor addresses. >> >> OVS crash for example: >> <------------------------------------------------------------------------> >> [test-pmd inside guest VM] >> >> testpmd> port stop all >> Stopping ports... >> Checking link statuses... >> Port 0 Link Up - speed 10000 Mbps - full-duplex >> Done >> testpmd> port config all rxq 2 >> testpmd> port config all txq 2 >> testpmd> port start all >> Configuring Port 0 (socket 0) >> Port 0: 52:54:00:CB:44:C8 >> Checking link statuses... >> Port 0 Link Up - speed 10000 Mbps - full-duplex >> Done > > I actually didn't manage to reproduce it on my side, with the > vhost-example instead of OVS though. Is that all the commands > to reproduce it, and run them just after start test-pmd? Actually, I think, packet flow should be enabled while performing above actions and some traffic already should be sent through port to change last used idx on vhost side. Something like: start ..wait a while.. see that packets are flowing. stop port stop port config port config port start > >> [OVS on host] >> Program received signal SIGSEGV, Segmentation fault. >> rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) at rte_memcpy.h >> >> (gdb) bt >> #0 rte_memcpy (n=2056, src=0xc, dst=0x7ff4d5247000) >> #1 copy_desc_to_mbuf >> #2 rte_vhost_dequeue_burst >> #3 netdev_dpdk_vhost_rxq_recv >> ... >> >> (gdb) bt full >> #0 rte_memcpy >> ... >> #1 copy_desc_to_mbuf >> desc_addr = 0 >> mbuf_offset = 0 >> desc_offset = 12 >> ... >> <------------------------------------------------------------------------> >> >> Fix that by checking addresses of descriptors before using them. >> >> Note: For mergeable buffers this patch checks only guest's address for >> zero, but in non-meargeable case host's address checked. This is done >> because checking of host's address in mergeable case requires additional >> refactoring to keep virtqueue in consistent state in case of error. >> >> Signed-off-by: Ilya Maximets >> --- >> >> Actually, current virtio implementation looks broken for me. Because >> 'virtio_dev_start' breaks virtqueue while it still available from the vhost >> side. >> >> There was 2 patches about this behaviour: >> >> 1. a85786dc816f ("virtio: fix states handling during initialization") >> 2. 9a0615af7746 ("virtio: fix restart") >> >> The second patch fixes somehow issue intoduced in the first patch, but actually >> also breaks vhost in the way described above. >> It's not pretty clear for me what to do in current situation with virtio, >> because it will be broken for guest application even if vhost will not crash. >> >> May be it'll be better to forbid stopping of virtio device and force user to >> exit and start again (may be implemented in hidden from user way)? >> >> This patch adds additional sane checks, so it should be applied anyway, IMHO. > > Agreed. > > --yliu > >