From patchwork Tue Apr 12 10:34:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= X-Patchwork-Id: 8809151 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 32083C0553 for ; Tue, 12 Apr 2016 10:34:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4A7F520351 for ; Tue, 12 Apr 2016 10:34:27 +0000 (UTC) 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.kernel.org (Postfix) with ESMTPS id 22816200E8 for ; Tue, 12 Apr 2016 10:34:26 +0000 (UTC) Received: from localhost ([::1]:46537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apveL-0007rD-4p for patchwork-qemu-devel@patchwork.kernel.org; Tue, 12 Apr 2016 06:34:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apveD-0007nx-4b for qemu-devel@nongnu.org; Tue, 12 Apr 2016 06:34:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apve7-0005AN-9c for qemu-devel@nongnu.org; Tue, 12 Apr 2016 06:34:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apve7-00059v-5Y for qemu-devel@nongnu.org; Tue, 12 Apr 2016 06:34:11 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BBF9E78224; Tue, 12 Apr 2016 10:34:09 +0000 (UTC) Received: from redhat.com (vpn1-7-45.ams2.redhat.com [10.36.7.45]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3CAY6TW022051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Apr 2016 06:34:08 -0400 Date: Tue, 12 Apr 2016 11:34:06 +0100 From: "Daniel P. Berrange" To: Alex Bligh Message-ID: <20160412103406.GA28370@redhat.com> References: <5705727B.1000802@redhat.com> <20160409091634.GB19023@grep.be> <20160409102833.GL19023@grep.be> <20160409113225.GR19023@grep.be> <20160410082710.GA28660@grep.be> <91E6DE09-E8F3-489E-B1F2-B3ECC358BB75@alex.org.uk> <20160412094820.GA8122@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160412094820.GA8122@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [Nbd] NBD_CMD_DISC 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: , Reply-To: "Daniel P. Berrange" Cc: "nbd-general@lists.sourceforge.net" , Wouter Verhelst , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Apr 12, 2016 at 10:48:20AM +0100, Daniel P. Berrange wrote: > On Sun, Apr 10, 2016 at 10:49:00AM +0100, Alex Bligh wrote: > > (Daniel: if you want to replicate the issue, just run qemu-img info > > against my gonbdserver with TLS. Every fifth NBD_CMD_DISC doesn't > > get through before the TCP session closes). > > Hmm, I'll have a look at this - I'm not sure its caused by > the lack of gnutls_bye, as opposed to incorrect handling > of EAGAIN when the block layer sends CMD_DISC I have tried to reproduce with your server yet, but I did look at the code and identified one potential flaw that might cause the behaviour you mention. Can you try testing with the following change applied to QEMU: The current code will cause it to silently not send CMD_DISC if the socket returns EAGAIN on send(). This change will cause it to do a poll to wait and retry the send(). That said I'd be pretty surprised if we do actually get EAGAIN in this scenario, as I'd expect the outgoing TCP buffers to be empty at the point in which we close the client connection, but this fix is worth a try. Regards, Daniel diff --git a/nbd/common.c b/nbd/common.c index 8ddb2dd..47757b6 100644 --- a/nbd/common.c +++ b/nbd/common.c @@ -50,7 +50,7 @@ ssize_t nbd_wr_syncv(QIOChannel *ioc, * qio_channel_yield() that works with AIO contexts * and consider using that in this branch */ qemu_coroutine_yield(); - } else if (done) { + } else if (done || !do_read) { /* XXX this is needed by nbd_reply_ready. */ qio_channel_wait(ioc, do_read ? G_IO_IN : G_IO_OUT);