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 ABE0B6A6A for ; Mon, 30 May 2016 13:05:10 +0200 (CEST) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O7Z00E7WLGK2I30@mailout2.w1.samsung.com> for dev@dpdk.org; Mon, 30 May 2016 12:05:08 +0100 (BST) X-AuditID: cbfec7f4-f796c6d000001486-ce-574c1e6481aa Received: from eusync2.samsung.com ( [203.254.199.212]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id E9.8A.05254.46E1C475; Mon, 30 May 2016 12:05:08 +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 <0O7Z00MNFLGJNX10@eusync2.samsung.com>; Mon, 30 May 2016 12:05:08 +0100 (BST) To: Yuanhan Liu References: <1463748604-27251-1-git-send-email-i.maximets@samsung.com> <20160523105726.GI5641@yliu-dev.sh.intel.com> <5742E3C2.9090309@samsung.com> Cc: dev@dpdk.org, Huawei Xie , Dyasly Sergey , Heetae Ahn , Jianfeng Tan From: Ilya Maximets Message-id: <574C1E63.3070000@samsung.com> Date: Mon, 30 May 2016 14:05:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-version: 1.0 In-reply-to: <5742E3C2.9090309@samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsVy+t/xK7opcj7hBlOniFq8+7SdyWLa59vs Fu0zzzJZXGn/yW7RPfsLm8Xk2VIW1ydcYHVg9/i1YCmrx+I9L5k85p0M9OjbsooxgCWKyyYl NSezLLVI3y6BK2PKlBOsBS2yFb3XfrA0MN4Q62Lk5JAQMJG4OPEEK4QtJnHh3nq2LkYuDiGB pYwSrRdXs0M4LxglDu9fywxSJSzgLDHhbB8jiC0ioCvxdM46VoiiqYwSi+beB+tgFljNKHH3 9SoWkCo2AR2JU6uPgHXwCmhJnP46ESjOwcEioCqx9oMoSFhUIEJi1vYfTBAlghI/Jt8Da+UU 0Ja4PP86I0g5s4CexP2LWiBhZgF5ic1r3jJPYBSYhaRjFkLVLCRVCxiZVzGKppYmFxQnpeca 6hUn5haX5qXrJefnbmKEBPaXHYyLj1kdYhTgYFTi4S3Q9A4XYk0sK67MPcQowcGsJMIbJusT LsSbklhZlVqUH19UmpNafIhRmoNFSZx37q73IUIC6YklqdmpqQWpRTBZJg5OqQbGmDsF6hM+ T5j70oItlXPiIc2D139ypG2xLpB+9s6sJoijLfWgyKbcDwfmr7ysxr52sg3HglPPUhddOrPh 1kzhY+eckqbd1ObbcnzH/Ukvq0JXnLz2+19htJzKAvkk67Knhpvsox5oNPxt5E6V3p8aw/Dm 8lU9uwdK7162NMS+nBy/OP+cy9u7OUosxRmJhlrMRcWJADR0jeZoAgAA 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, 30 May 2016 11:05:10 -0000 Ping. Best regards, Ilya Maximets. On 23.05.2016 14:04, Ilya Maximets wrote: > 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 >> >>