From patchwork Tue Mar 13 17:13:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 10280289 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B30DB602BD for ; Tue, 13 Mar 2018 17:39:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9F8D6289BE for ; Tue, 13 Mar 2018 17:39:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9356A28A1C; Tue, 13 Mar 2018 17:39:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 19507289BE for ; Tue, 13 Mar 2018 17:39:55 +0000 (UTC) Received: from localhost ([::1]:41547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evntx-0004x0-2K for patchwork-qemu-devel@patchwork.kernel.org; Tue, 13 Mar 2018 13:39:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evnUp-0007Hk-7e for qemu-devel@nongnu.org; Tue, 13 Mar 2018 13:13:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evnUn-0000q3-Sv for qemu-devel@nongnu.org; Tue, 13 Mar 2018 13:13:55 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56964 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1evnUk-0000l3-CQ; Tue, 13 Mar 2018 13:13:50 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C18D4023BB3; Tue, 13 Mar 2018 17:13:50 +0000 (UTC) Received: from red.redhat.com (ovpn-121-135.rdu2.redhat.com [10.10.121.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B1C72026DFD; Tue, 13 Mar 2018 17:13:49 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 13 Mar 2018 12:13:32 -0500 Message-Id: <20180313171345.659672-5-eblake@redhat.com> In-Reply-To: <20180313171345.659672-1-eblake@redhat.com> References: <20180313171345.659672-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 13 Mar 2018 17:13:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 13 Mar 2018 17:13:50 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 04/17] nbd/server: fix: check client->closing before sending reply X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Vladimir Sementsov-Ogievskiy , "open list:Network Block Dev..." Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: Vladimir Sementsov-Ogievskiy Since the unchanged code has just set client->recv_coroutine to NULL before calling nbd_client_receive_next_request(), we are spawning a new coroutine unconditionally, but the first thing that coroutine will do is check for client->closing, making it a no-op if we have already detected that the client is going away. Furthermore, for any error other than EIO (where we disconnect, which itself sets client->closing), if the client has already gone away, we'll probably encounter EIO later in the function and attempt disconnect at that point. Logically, as soon as we know the connection is closing, there is no need to try a likely-to-fail a response or spawn a no-op coroutine. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-Id: <20180308184636.178534-4-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake [eblake: squash in further reordering: hoist check before spawning next coroutine, and document rationale in commit message] Signed-off-by: Eric Blake --- nbd/server.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/nbd/server.c b/nbd/server.c index 5f292064af0..b230ecb4fb8 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -1543,14 +1543,6 @@ static coroutine_fn void nbd_trip(void *opaque) req = nbd_request_get(client); ret = nbd_co_receive_request(req, &request, &local_err); client->recv_coroutine = NULL; - nbd_client_receive_next_request(client); - if (ret == -EIO) { - goto disconnect; - } - - if (ret < 0) { - goto reply; - } if (client->closing) { /* @@ -1560,6 +1552,15 @@ static coroutine_fn void nbd_trip(void *opaque) goto done; } + nbd_client_receive_next_request(client); + if (ret == -EIO) { + goto disconnect; + } + + if (ret < 0) { + goto reply; + } + switch (request.type) { case NBD_CMD_READ: /* XXX: NBD Protocol only documents use of FUA with WRITE */