From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 49C56A0096 for ; Wed, 10 Apr 2019 09:53:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D16715F28; Wed, 10 Apr 2019 09:53:42 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 4DB3D5F0D for ; Wed, 10 Apr 2019 09:53:41 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190410075340euoutp029a0e2f8e606ed0755030b5bfc20fc5c2~UDa-rwtVf2626426264euoutp028 for ; Wed, 10 Apr 2019 07:53:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190410075340euoutp029a0e2f8e606ed0755030b5bfc20fc5c2~UDa-rwtVf2626426264euoutp028 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1554882820; bh=pIJW7jk9plQHae64bGjPWxEnePxftvbzPKBrL5tpKtM=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=DMbklzP691fHZPsmkrwxwsrgwwzNkJZMo1g3fPTvc8Xu0c0X9aMSQ6yG51eSFrCz9 nixTfzpPrXq59RyN3CELkz9wJlDyxf5qsWoBcV6rAH1C+IvCJAfCSAgCgulTvV7qyb SX0bGUkE1C4DXto7tIqTm33qXiYDyTjkkPob9zvE= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20190410075339eucas1p14c62d7fdb43ad20b1898a85e94c6b16a~UDa-E29n_1893918939eucas1p17; Wed, 10 Apr 2019 07:53:39 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 10.1A.04298.301ADAC5; Wed, 10 Apr 2019 08:53:39 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20190410075339eucas1p23be66e59b34a44cee3bb06e2b16dc162~UDa_RckF30970409704eucas1p2t; Wed, 10 Apr 2019 07:53:39 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20190410075338eusmtrp2c941a9738bc2db16b9166224b64bd13e~UDa_DV_0n0430004300eusmtrp2R; Wed, 10 Apr 2019 07:53:38 +0000 (GMT) X-AuditID: cbfec7f2-f2dff700000010ca-d8-5cada103347c Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 99.83.04146.201ADAC5; Wed, 10 Apr 2019 08:53:38 +0100 (BST) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20190410075338eusmtip148c44306c6d54bd7eac724a5f99459a1~UDa9gwKRV1506015060eusmtip1S; Wed, 10 Apr 2019 07:53:38 +0000 (GMT) To: David Marchand , Maxime Coquelin , Tiwei Bie Cc: dev , Jens Freimann , Dariusz Stojaczyk , dpdk stable From: Ilya Maximets Message-ID: <2419f57d-3283-0fae-745d-002d7ff500e7@samsung.com> Date: Wed, 10 Apr 2019 10:53:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsWy7djPc7rMC9fGGOz/oWGxbH8ri8X2FV1s Fu8+bWeyuNL+k93i3JqlLBbHOvewWPzr+MNusbXhP5MDh8evBUtZPRbvecnk8X7fVTaPvi2r GANYorhsUlJzMstSi/TtErgyFvSfZSlYKVhx88YjxgbG87xdjJwcEgImEttePWTqYuTiEBJY wSix5uM5dgjnC6PE7s6TbBDOZ0aJI8s6mGBaep9+YoRILGeUWPBsElT/R0aJCUd3MINUCQv4 SPw5v4gVxBYRqJdo7XnLClLELNDPKNEyeypYgk1AR+LU6iOMIDavgJ3EtNf/wFawCKhK3FjT xgJiiwpESNw/toEVokZQ4uTMJ2BxToFAiZ99S8BsZgFxiaYvK1khbHmJ5q2zmSFO3cYu8WKZ M4TtIrHg3RdWCFtY4tXxLewQtozE/53zoV6rl7jf8hLsNQmBDkaJ6Yf+QSXsJba8BoUMB9AC TYn1u/Qhwo4S69Z9YgMJSwjwSdx4KwhxAp/EpG3TmSHCvBIdbUIQ1SoSvw8uh7pMSuLmu8/s ExiVZiF5bBaSZ2YheWYWwt4FjCyrGMVTS4tz01OLDfNSy/WKE3OLS/PS9ZLzczcxAtPQ6X/H P+1g/Hop6RCjAAejEg9vxLw1MUKsiWXFlbmHGCU4mJVEeD++AQrxpiRWVqUW5ccXleakFh9i lOZgURLnrWZ4EC0kkJ5YkpqdmlqQWgSTZeLglGpg5BJ5z/jmScfv9+9MPzGcfzNpu/mUh5Hr /c/6L+XlO1B9vjG7cvHpz3P3xXhGJFRN2yu9x+7yvydntgu/fvK+QeGQz6+/W+/VPf7hGxzU d+LdigMKDp/Splb9XBS5Kkhpe5Zp7fWG9w2H+mUPJzJ6/tnHFWB4X/p6FsuSlqlexW4lf6LZ +BcfUFZiKc5INNRiLipOBAClzUkWPwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsVy+t/xu7pMC9fGGGy8r2uxbH8ri8X2FV1s Fu8+bWeyuNL+k93i3JqlLBbHOvewWPzr+MNusbXhP5MDh8evBUtZPRbvecnk8X7fVTaPvi2r GANYovRsivJLS1IVMvKLS2yVog0tjPQMLS30jEws9QyNzWOtjEyV9O1sUlJzMstSi/TtEvQy FvSfZSlYKVhx88YjxgbG87xdjJwcEgImEr1PPzF2MXJxCAksZZTY+m8LK0RCSuLHrwtQtrDE n2tdbBBF7xklfrzczQaSEBbwkfhzfhFYkYhAvcSWUwuZQIqYBSYySlxuWsQEkhASuMYo8f2x NIjNJqAjcWr1EUYQm1fATmLa639gNSwCqhI31rSxgNiiAhESZ96vYIGoEZQ4OfMJmM0pECjx s28JmM0soC7xZ94lZghbXKLpy0pWCFteonnrbOYJjEKzkLTPQtIyC0nLLCQtCxhZVjGKpJYW 56bnFhvqFSfmFpfmpesl5+duYgRG3rZjPzfvYLy0MfgQowAHoxIPb8D0NTFCrIllxZW5hxgl OJiVRHg/vgEK8aYkVlalFuXHF5XmpBYfYjQFem4is5Rocj4wKeSVxBuaGppbWBqaG5sbm1ko ifOeN6iMEhJITyxJzU5NLUgtgulj4uCUamDMWGI1Z2b9F52TNZ58oeYq2RdeSE6beWyy5Ozq hUZ37rJ/5+IoV4w/co5zf8SRvoqNhQGcvzx5WH495jquF+z5+NjsiPKOyl+e/qLm2d1h+UXS /S/XXtqSVGZ023nK/14ZO9cbQXt+3PE+tntNvonY+zVGP/1yM69xsqUHnl0p0efhJ921fb8S S3FGoqEWc1FxIgC4aRMp0gIAAA== X-CMS-MailID: 20190410075339eucas1p23be66e59b34a44cee3bb06e2b16dc162 X-Msg-Generator: CA Content-Type: text/plain; charset="UTF-8" X-RootMTR: 20190409133629eucas1p2ecfe7c4771bb6add694596cf75cf3e70 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190409133629eucas1p2ecfe7c4771bb6add694596cf75cf3e70 References: <20190409133622.14729-1-i.maximets@samsung.com> Subject: Re: [dpdk-dev] [PATCH] vhost: fix passing destroyed device to destroy callback 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190410075332.PpIRB78wGoyaD2chDE7aL_swZIGewDifyxbWwdbN71w@z> On 10.04.2019 10:24, David Marchand wrote: > > > On Tue, Apr 9, 2019 at 3:36 PM Ilya Maximets > wrote: > > Application should be able to obtain information like 'ifname' from > the 'vid' passed to 'destroy_connection' callback. Currently, all the > API calls with passed 'vid' fails with 'device not found'. > > Fixes: efba12a78ddf ("vhost: add user callbacks for socket open/close") > Cc: stable@dpdk.org > > Signed-off-by: Ilya Maximets > > --- >  lib/librte_vhost/socket.c | 3 ++- >  1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c > index 3da9de62c..43f091d10 100644 > --- a/lib/librte_vhost/socket.c > +++ b/lib/librte_vhost/socket.c > @@ -297,11 +297,12 @@ vhost_user_read_cb(int connfd, void *dat, int *remove) >         if (ret < 0) { >                 close(connfd); >                 *remove = 1; > -               vhost_destroy_device(conn->vid); > >                 if (vsocket->notify_ops->destroy_connection) >                         vsocket->notify_ops->destroy_connection(conn->vid); > > +               vhost_destroy_device(conn->vid); > + >                 pthread_mutex_lock(&vsocket->conn_mutex); >                 TAILQ_REMOVE(&vsocket->conn_list, conn, next); >                 pthread_mutex_unlock(&vsocket->conn_mutex); > -- > 2.17.1 > > > Reviewed-by: David Marchand > > > For vhost maintainers, looking at vhost_user_add_connection, aren't we leaking a vid on errors ? either when new_connection notifier returns an error, or after calling destroy_connection. I think that you're right. I spotted that too yesterday while preparing this patch, just had no time to check deeper. It should be safe to call 'vhost_destroy_device' in these cases. Best regards, Ilya Maximets.