From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuHUB-0005lE-7m for qemu-devel@nongnu.org; Wed, 03 Jul 2013 03:28:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuHU8-0003Bu-Td for qemu-devel@nongnu.org; Wed, 03 Jul 2013 03:28:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuHU8-0003BX-IU for qemu-devel@nongnu.org; Wed, 03 Jul 2013 03:28:16 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r637SFQ9030993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Jul 2013 03:28:15 -0400 Message-ID: <51D3D286.8020909@redhat.com> Date: Wed, 03 Jul 2013 09:28:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1372744789-997-1-git-send-email-famz@redhat.com> <1372744789-997-4-git-send-email-famz@redhat.com> <51D2A890.4060806@redhat.com> <20130703011009.GE1949@t430s.nay.redhat.com> <51D3BD75.4030408@redhat.com> <20130703063030.GA1112@t430s.nay.redhat.com> In-Reply-To: <20130703063030.GA1112@t430s.nay.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/7] nbd: use BDS refcount List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: famz@redhat.com Cc: kwolf@redhat.com, rjones@redhat.com, obarenbo@redhat.com, roliveri@redhat.com, hbrock@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, pmyers@redhat.com, imain@redhat.com, stefanha@redhat.com Il 03/07/2013 08:30, Fam Zheng ha scritto: >> > The close notifier runs when the user invokes a drive_del or eject >> > command from the monitor. The drive_get_ref/drive_put_ref delays the >> > bdrv_delete until after nbd.c has cleaned up all the connections. > But drive_put_ref is called by close notifier. Not necessarily. nbd_export_close calls nbd_client_close, which shuts down the socket. However, if requests are being processed, they will complete after nbd_export_close returns. Completing the requests leads to the following call chain: nbd_request_put (from nbd_trip) calls nbd_client_put calls nbd_export_put calls exp->close (if refcount goes to 0) calls drive_put_ref Completion will happen as soon as the main loop runs again, because after shutdown() the reads and writes will fail. Still, it is asynchronous, hence the call to drive_put_ref is also asynchronous. > I think it can be > omitted, registering a close notifier is enough, and close the export > when drive_del calls it. It doesn't make more sense w/ drive_get_ref, > does it? I think that would cause a dangling pointer if NBD requests are being processed at the time drive_del runs. Paolo