Re: [dpdk-dev] [PATCH] net/vhost: fix segfault when creating vdev dynamically

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 03/27/2018 11:42 AM, Tan, Jianfeng wrote:
> 
> 
> On 3/27/2018 5:24 PM, Chen, Junjie J wrote:
>>>>> On 3/28/2018 12:05 AM, Junjie Chen wrote:
>>>>>> when creating vdev dynamically, vhost pmd driver start directly
>>>>>> without checking TX/RX queues ready or not, and thus cause
>>>>>> segmentation fault when vhost library accessing queues. This patch
>>>>>> add flag to check whether queues setup or not, and add driver start
>>>>>> call into dev_start to allow user start it after setting up queue.
>>>>> The issue is clear now. But this patch just puts the situation 
>>>>> before below
>>> fix:
>>>>> "it doesn't create the actual datagram socket until you call 
>>>>> .dev_start()."
>>>> No, if the queue exist, the datagram socket still get created in 
>>>> vhost_create
>>> API, since the vhost_driver_register still exist in vhost_create.
>>>
>>> The queue can never be created, as it's still not probed.
>> I think we need to separate this into two cases:
>>     Statically create vdev, the datagram recreate logical is still 
>> there since queues are exist already, this patch doesn't change anything.
>>     Dynamic create vdev, as you pointed out, queue can never be 
>> created, while this should be not valid since In normal process of 
>> creating vdev dynamically, we always need to config queues. Correct me 
>> if I'm wrong.
> 
> My point is, either vdev is created statically or dynamically, when 
> probe(), queues are not setup yet definitely, then *the unix socket will 
> not be created* until we set up the queues and do dev_start(). If the 
> unix socket is not created, then VM cannot connect to it.

FYI, I think I reproduced such an issue with the vdev statically created
in the past, while doing some experiments. I didn't went further into 
the analysis at that time, but it looks like the issue Junjie is trying
to address with this patch for dynamically created vdev.

Cheers,
Maxime
>> In summary, I think the previously commit fixes the static code path 
>> and this patch fixes the dynamic code path (we need to at least setup 
>> queue once).
>