From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E9D0EA0524; Fri, 6 Nov 2020 09:08:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 37BCE2BEA; Fri, 6 Nov 2020 09:08:02 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id 9347D2BEA for ; Fri, 6 Nov 2020 09:07:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604650078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t2BaQ6rZwT6eBaLtaDTv7Ljp1JMqDA6yDGJnRNat7iY=; b=BAOL9AER4D04ubNIVhwbOaitqzSkT9aJanWb5hC8YxMHxIeInxvIwqlhWlC7m1Vnv1d2Rk cXAJPvsLyVud9CaIStL7uTKLJxQTCfHsSxD4bFPO17ifSnWkRmWt5CxboYUhNJ31pfUVVD 93G3hF7qN7/gfdZgzrg/p7HqJJ8fyf4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-193-zY7zW498Neyi9mwdnxOsoA-1; Fri, 06 Nov 2020 03:07:56 -0500 X-MC-Unique: zY7zW498Neyi9mwdnxOsoA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B77961009E26; Fri, 6 Nov 2020 08:07:54 +0000 (UTC) Received: from [10.36.110.29] (unknown [10.36.110.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DD4E15C5DE; Fri, 6 Nov 2020 08:07:52 +0000 (UTC) To: "Xia, Chenbo" , "dev@dpdk.org" , "Ding, Xuan" , "stephen@networkplumber.org" , "Yigit, Ferruh" , "thomas@monjalon.net" Cc: "stable@dpdk.org" References: <20201105114549.97717-1-maxime.coquelin@redhat.com> <20201105114549.97717-3-maxime.coquelin@redhat.com> From: Maxime Coquelin Message-ID: Date: Fri, 6 Nov 2020 09:07:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/3] vhost: fix fd leak in dirty logging setup 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" On 11/6/20 3:53 AM, Xia, Chenbo wrote: > Hi Maxime, > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Thursday, November 5, 2020 7:46 PM >> To: dev@dpdk.org; Ding, Xuan ; >> stephen@networkplumber.org; Yigit, Ferruh ; >> thomas@monjalon.net; Xia, Chenbo >> Cc: stable@dpdk.org; Maxime Coquelin >> Subject: [PATCH 2/3] vhost: fix fd leak in dirty logging setup >> >> This patch fixes a file descriptor leak which happens >> in the error path of vhost_user_set_log_base(). >> >> Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application") >> Cc: stable@dpdk.org >> >> Reported-by: Xuan Ding >> Signed-off-by: Maxime Coquelin >> --- >> lib/librte_vhost/vhost_user.c | 10 +++++++--- >> 1 file changed, 7 insertions(+), 3 deletions(-) >> >> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c >> index 473fd778ca..7dfda15991 100644 >> --- a/lib/librte_vhost/vhost_user.c >> +++ b/lib/librte_vhost/vhost_user.c >> @@ -2076,14 +2076,14 @@ vhost_user_set_log_base(struct virtio_net **pdev, >> struct VhostUserMsg *msg, >> >> if (fd < 0) { >> VHOST_LOG_CONFIG(ERR, "invalid log fd: %d\n", fd); >> - return RTE_VHOST_MSG_RESULT_ERR; >> + goto close_msg_fds; > > IMHO, there's nothing to close in this case. Before this check, validate_msg_fds > makes sure that this msg has only one fd and now this fd is invalid. So when this > error occurs, going to close_msg_fds always does nothing. So I think we don't need > this change here? Thanks for the detailed review. Yes, you are right, we can simply return here as before since no FD are to close. I will post v2 soon. Thanks, Maxime > Thanks! > Chenbo