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 AC586A09EA; Wed, 9 Dec 2020 12:34:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DA6B9BE77; Wed, 9 Dec 2020 12:34:09 +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 C8139BE73 for ; Wed, 9 Dec 2020 12:34:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607513646; 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=5JeCttDxvn5KGerEUEp+9JcON20Qcm7Gb5a8R5Kr3yk=; b=UI3ErYNeWDfa2R27K2HewtU+9CVBchRvhB3mkQc9h0YdSMnwYNWohssyD3YGMM90zqaNQ8 dJnTHrGBYon5KU8CvTXX0/UyMjzKQph1GQXtZiEt42IYmXglj6/YQqJwCwuxJXJTpdPqeF kmIK1ey3vE5cz7Yr/4/RzBwzuegwPN4= 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-495-9uahMmaeP4awzjd99Ya1_Q-1; Wed, 09 Dec 2020 06:34:03 -0500 X-MC-Unique: 9uahMmaeP4awzjd99Ya1_Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BB1F5AFA81; Wed, 9 Dec 2020 11:34:01 +0000 (UTC) Received: from [10.36.110.22] (unknown [10.36.110.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DBB511042989; Wed, 9 Dec 2020 11:33:59 +0000 (UTC) To: "Xia, Chenbo" , Jiawei Zhu <17826875952@163.com>, "dev@dpdk.org" Cc: "liweifeng2@huawei.com" , "zhujiawei12@huawei.com" , "stable@dpdk.org" References: <1606575020-2973-1-git-send-email-17826875952@163.com> From: Maxime Coquelin Message-ID: Date: Wed, 9 Dec 2020 12:33:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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] net/virtio-user: fix error run close(0) 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 12/9/20 12:31 PM, Xia, Chenbo wrote: > Hi Jiawei, > > Thanks for catching this! > Comments inline. > >> -----Original Message----- >> From: Jiawei Zhu <17826875952@163.com> >> Sent: Saturday, November 28, 2020 10:50 PM >> To: dev@dpdk.org >> Cc: liweifeng2@huawei.com; zhujiawei12@huawei.com; maxime.coquelin@redhat.com; >> Xia, Chenbo >> Subject: [PATCH] net/virtio-user: fix error run close(0) >> >> From: Jiawei Zhu >> >> When i < VIRTIO_MAX_VIRTQUEUES and j == i, >> dev->callfds[i] and dev->kickfds[i] are default 0. >> So it will close(0), close the standard input (stdin). >> >> Fixes: e6e7ad8b3024 ("net/virtio-user: move eventfd open/close into >> init/uninit") >> Cc: stable@dpdk.org >> >> Signed-off-by: Jiawei Zhu >> --- >> drivers/net/virtio/virtio_user/virtio_user_dev.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c >> b/drivers/net/virtio/virtio_user/virtio_user_dev.c >> index 053f026..1bfd223 100644 >> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c >> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c >> @@ -284,7 +284,7 @@ int virtio_user_stop_device(struct virtio_user_dev *dev) >> } >> >> if (i < VIRTIO_MAX_VIRTQUEUES) { >> - for (j = 0; j <= i; ++j) { >> + for (j = 0; j < i; ++j) { > > With the help of your patch, I notice another defect that if the code fails in kickfd > creation, we will leave one callfd not closed. Since you are here, could you help solve > this too? A potential solution could be doing 'dev->callfds[i] = callfd' just after callfd > creation, keeping 'j <= i' and adding checks before close(). What do you think? +1, I noticed the same discussing the patch with David. > Btw, I noticed that you have sent multiple patches that have same content. If you want to > send new version. Please --in-reply-to this patch as this is the one that shows in patchwork. > (http://patchwork.dpdk.org/patch/84626/) I personally don't care about the --in-reply-to, but I agree for the versioning. Thanks, Maxime > Thanks! > Chenbo > >> close(dev->callfds[j]); >> close(dev->kickfds[j]); >> } >> -- >> 1.8.3.1 >