Hi Tiwei,
On 2/19/20 4:44 AM, Tiwei Bie wrote:
> On Tue, Feb 18, 2020 at 06:22:40PM +0100, Maxime Coquelin wrote:
>> Ethdev's .dev_configure callback can be called multiple
>> time during a device life-time, but Vhost makes the
>> wrong assumption that it is not the case and try to
>> setup again the device on reconfiguration.
>>
>> This patch ensures the device hasn't been already setup
>> before proceeding.
>>
>> Fixes: 3d01b759d267 ("net/vhost: delay driver setup")
>>
>> Reported-by: Yinan Wang <yinan.w...@intel.com>
>> Signed-off-by: Maxime Coquelin <maxime.coque...@redhat.com>
>> Tested-by: Yinan Wang <yinan.w...@intel.com>
>> Reviewed-by: David Marchand <david.march...@redhat.com>
>> ---
>> drivers/net/vhost/rte_eth_vhost.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/vhost/rte_eth_vhost.c
>> b/drivers/net/vhost/rte_eth_vhost.c
>> index 4a7b1b608c..458ed58f5f 100644
>> --- a/drivers/net/vhost/rte_eth_vhost.c
>> +++ b/drivers/net/vhost/rte_eth_vhost.c
>> @@ -876,6 +876,11 @@ vhost_driver_setup(struct rte_eth_dev *eth_dev)
>> unsigned int numa_node = eth_dev->device->numa_node;
>> const char *name = eth_dev->device->name;
>>
>> + /* Don't try to setup again if it has already been done. */
>> + list = find_internal_resource(internal->iface_name);
>> + if (list)
>> + return 0;
>> +
>> list = rte_zmalloc_socket(name, sizeof(*list), 0, numa_node);
>> if (list == NULL)
>> return -1;
>> --
>> 2.24.1
>
> Thanks Maxime for the fix!
>
> Reviewed-by: Tiwei Bie <tiwei....@intel.com>
>
> Not related to this fix, it seems there is a potential leak after
> delaying the driver setup to _configure, as the list won't be
> registered until users configure the device. So internal->iface_name
> allocated in _create will leak if the device is released without
> doing _configure first.
>
> https://github.com/DPDK/dpdk/blob/e6c78e736d77/drivers/net/vhost/rte_eth_vhost.c#L1058
> https://github.com/DPDK/dpdk/blob/e6c78e736d77/drivers/net/vhost/rte_eth_vhost.c#L1075
>
> It's not a common case and it's quite late in this release,
> probably it's fine to fix it later.
That's a valid point, and I also agree there is no urgency for v20.02.
Itsuro, would you take care of fixing it for v20.05?
Thanks,
Maxime
> Thanks,
> Tiwei
>
