Message ID | 20230530203116.2008-17-demi@invisiblethingslab.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2451128vqr; Tue, 30 May 2023 13:46:11 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7x8ZoCE78C0FM6BmFLs69zVReeb0sBqMHNvQ5Sa7gtEuQSqQvRANO0aSC3oIC5QiNxoV34 X-Received: by 2002:a17:90b:d0b:b0:256:4189:2b0d with SMTP id n11-20020a17090b0d0b00b0025641892b0dmr3830284pjz.12.1685479571421; Tue, 30 May 2023 13:46:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685479571; cv=none; d=google.com; s=arc-20160816; b=0JbRr+qRd0L8k87fg1RvPd0KmSHB/WZpnn3J/ojtGf5TufmEJsGtPEC+UVq8rlTkmP zhvxgUtuJtFFBE5BSG4C4uEj74I3rl0/OElQBdUHztsgYlAajwfwXoam5VJZ46pAj2jz K8j7Q2QjmroSFH2j2cmkDjRbNWIxW69K3DHovNtMrHP2jJdCUtquahDFFT5y20Vn5k/0 jucfx7u2+unKqDrRD02XNai/LO/YrWk3H2HBzGl00leM0lArdQf1IaxUCjhaHjvIG/Qp eGteGQLADuZUXrpvH2pCPBorao6v4kihrGsrsHtruGrUYKjwHJoqZvdnfe2nsox24sU7 CH9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :feedback-id:dkim-signature:dkim-signature; bh=gJtXKfjMb5k3PryJlBFsKsS3ZINd0EksqBFZ4ekKEDw=; b=deYT/eAwc8gkA0LPAucyVZ4QIK+TFRJM/mDU2hSVQ/GH5wz8yz72UR2MZjCF4DrTAZ /V5n5+2PVU0WgrKnt5Gfw5zBim8qM02/2YKlhqE0ulzv12RPUe42m+MCZEE3nPuSgOQg F0YnwZ2mJBCk+KOs0qqT2mXZXngtOa3/ICljEJgRkkn2IuuUmMS88N2diZgMqFLmbtwj jONfQhTsZ/OgWkvSk/OhMM9YiHwx6NOSMHVqAmKR85/BJ2zx9aNIWvO3mj/lwFGLHjJ9 +tJkNG920I84WNx0WEzTIiQwccX+gjQrMe1iCsUbR8gvHMdSgLd1E9NdA3h9tcF9f+zV iiiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@invisiblethingslab.com header.s=fm1 header.b=iSW8ttt2; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=oQbHhAjd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ip14-20020a17090b314e00b00250cb2a2000si13139340pjb.113.2023.05.30.13.45.59; Tue, 30 May 2023 13:46:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@invisiblethingslab.com header.s=fm1 header.b=iSW8ttt2; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=oQbHhAjd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233527AbjE3UeM (ORCPT <rfc822;andrewvogler123@gmail.com> + 99 others); Tue, 30 May 2023 16:34:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229893AbjE3UeJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 30 May 2023 16:34:09 -0400 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50BDDE42; Tue, 30 May 2023 13:33:32 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0D022320096E; Tue, 30 May 2023 16:32:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 30 May 2023 16:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1685478740; x=1685565140; bh=gJtXKfjMb5 k3PryJlBFsKsS3ZINd0EksqBFZ4ekKEDw=; b=iSW8ttt26dngYvxurKxiOI2vd1 WHoQ92v7hwye8qiWm/sMzD3pqp5ya8c2OA22dKJKDKSCyzxijZP+Dp144KoNmvpt K8OI+kD4ismX23LXNvkYBIS8haogcvQd7EEZ19u32N/1GOR8sh6VaGOBsVQxw9Bq zrT17xw8paAPsuaett1MoyqWDe6uGCPznnCFymKvWzjN2rUubwy9Ob0uFq6jMg76 gqlN1m7Mc8Mkxu+yjAxvH0vX7/PlJqdVVec52wcaqJpFToYt9AxPY3yOgBt+RjEI aG4fzuzWpC22NKMBxr6O/RMjHdv28qKWfTHlwgkpaOz+BcWrwFwxRmGMeaMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1685478740; x= 1685565140; bh=gJtXKfjMb5k3PryJlBFsKsS3ZINd0EksqBFZ4ekKEDw=; b=o QbHhAjdGI/824Nl01Pip/x1ESJBxXGnNCUCk4Arc6BskEm0MTh9UC6MZYaR2q79S k1Uqb9Vj1z9f6r5u3H1HVCqm/h4f+Vs2C2I55ZxnoCF18+ZrNegBzgUSduwuENN3 ZelAmC1BB6EziOQZ1m0S4cDcLpBIGrjkaMEsTbam0kd7jHN3XymXk0VF7iAEn4+L g585WZp+QBIJWRDnqGJWJT85ZYmZick+DsS7QTOGtDLjDvulDczBAEFMf2pxjFDZ z70/jIsQbBWGVBj2a0QhQ3776f+UlGOsyvyOBXKD9nxTQaFTHfPjpO3nn2UqnNoO C4Idzu7QZyx3OsqotLhew== X-ME-Sender: <xms:VF12ZCx6LBtGDgihYZ-NBi1TQbMnT10K4M83ELm3G3ATfM8R279sSA> <xme:VF12ZOSoOZisX8Dh7PgaI1Br2VXmS17_-QQHdNrd8ODedLEjRJsiupF-ePxfF5-CL VIu0ou0rSk2fvk> X-ME-Received: <xmr:VF12ZEUZ2v-22K9HABN8joZIwupVm2l2OuN_SbATb71V0ubBkGLMjmuY97GOgzqwv3poc01Y0NU> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeekjedgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeffvghm ihcuofgrrhhivgcuqfgsvghnohhurhcuoeguvghmihesihhnvhhishhisghlvghthhhinh hgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeejffejgffgueegudevvdejkefg hefghffhffejteekleeufeffteffhfdtudehteenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeguvghmihesihhnvhhishhisghlvghthhhinhhg shhlrggsrdgtohhm X-ME-Proxy: <xmx:VF12ZIgsEEnwHKmC43Kv9GxV7bH-i7tiH_PkAz1p_2nBYwSEAf6YrA> <xmx:VF12ZEDqiN37KhUgZoqxnScnVqOaHAYoy7GmY53oxQjsejR59koZOQ> <xmx:VF12ZJLZp0lEBhXhDlI94ziBRaLfrp4UJrXDlteRIEm9FlDD8PS34w> <xmx:VF12ZCA0rxPCrK0M9295LprgFjyNUobhbd0Xa629Rogk5JO32xfXOA> Feedback-ID: iac594737:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 May 2023 16:32:19 -0400 (EDT) From: Demi Marie Obenour <demi@invisiblethingslab.com> To: Jens Axboe <axboe@kernel.dk>, =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com Cc: Demi Marie Obenour <demi@invisiblethingslab.com>, =?utf-8?q?Marek_Marczy?= =?utf-8?q?kowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v2 16/16] xen-blkback: Inform userspace that device has been opened Date: Tue, 30 May 2023 16:31:16 -0400 Message-Id: <20230530203116.2008-17-demi@invisiblethingslab.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230530203116.2008-1-demi@invisiblethingslab.com> References: <20230530203116.2008-1-demi@invisiblethingslab.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767353426712740594?= X-GMAIL-MSGID: =?utf-8?q?1767353426712740594?= |
Series |
Diskseq support in loop, device-mapper, and blkback
|
|
Commit Message
Demi Marie Obenour
May 30, 2023, 8:31 p.m. UTC
Set "opened" to "0" before the hotplug script is called. Once the
device node has been opened, set "opened" to "1".
"opened" is used exclusively by userspace. It serves two purposes:
1. It tells userspace that the diskseq Xenstore entry is supported.
2. It tells userspace that it can wait for "opened" to be set to 1.
Once "opened" is 1, blkback has a reference to the device, so
userspace doesn't need to keep one.
Together, these changes allow userspace to use block devices with
delete-on-close behavior, such as loop devices with the autoclear flag
set or device-mapper devices with the deferred-remove flag set.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
---
drivers/block/xen-blkback/xenbus.c | 35 ++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
Comments
On Tue, Jun 06, 2023 at 11:15:37AM +0200, Roger Pau Monné wrote: > On Tue, May 30, 2023 at 04:31:16PM -0400, Demi Marie Obenour wrote: > > Set "opened" to "0" before the hotplug script is called. Once the > > device node has been opened, set "opened" to "1". > > > > "opened" is used exclusively by userspace. It serves two purposes: > > > > 1. It tells userspace that the diskseq Xenstore entry is supported. > > > > 2. It tells userspace that it can wait for "opened" to be set to 1. > > Once "opened" is 1, blkback has a reference to the device, so > > userspace doesn't need to keep one. > > > > Together, these changes allow userspace to use block devices with > > delete-on-close behavior, such as loop devices with the autoclear flag > > set or device-mapper devices with the deferred-remove flag set. > > There was some work in the past to allow reloading blkback as a > module, it's clear that using delete-on-close won't work if attempting > to reload blkback. Should blkback stop itself from being unloaded if delete-on-close is in use? > Isn't there some existing way to check whether a device is opened? > (stat syscall maybe?). Knowing that the device has been opened isn’t enough. The block script needs to be able to wait for blkback (and not something else) to open the device. Otherwise it will be confused if the device is opened by e.g. udev. > I would like to avoid adding more xenstore blkback state if such > information can be fetched from other methods. I don’t think it can be, unless the information is passed via a completely different method. Maybe netlink(7) or ioctl(2)? Arguably this information should not be stored in Xenstore at all, as it exposes backend implementation details to the frontend. > > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c > > index 9c3eb148fbd802c74e626c3d7bcd69dcb09bd921..519a78aa9073d1faa1dce5c1b36e95ae58da534b 100644 > > --- a/drivers/block/xen-blkback/xenbus.c > > +++ b/drivers/block/xen-blkback/xenbus.c > > @@ -699,6 +713,14 @@ static int xen_blkbk_probe(struct xenbus_device *dev, > > if (err) > > pr_warn("%s write out 'max-ring-page-order' failed\n", __func__); > > > > + /* > > + * This informs userspace that the "opened" node will be set to "1" when > > + * the device has been opened successfully. > > + */ > > + err = xenbus_write(XBT_NIL, dev->nodename, "opened", "0"); > > + if (err) > > + goto fail; > > + > > You would need to set "opened" before registering the xenstore backend > watch AFAICT, or else it could be racy. Will fix in the next version.
On Wed, Jun 07, 2023 at 10:44:48AM +0200, Roger Pau Monné wrote: > On Tue, Jun 06, 2023 at 01:31:25PM -0400, Demi Marie Obenour wrote: > > On Tue, Jun 06, 2023 at 11:15:37AM +0200, Roger Pau Monné wrote: > > > On Tue, May 30, 2023 at 04:31:16PM -0400, Demi Marie Obenour wrote: > > > > Set "opened" to "0" before the hotplug script is called. Once the > > > > device node has been opened, set "opened" to "1". > > > > > > > > "opened" is used exclusively by userspace. It serves two purposes: > > > > > > > > 1. It tells userspace that the diskseq Xenstore entry is supported. > > > > > > > > 2. It tells userspace that it can wait for "opened" to be set to 1. > > > > Once "opened" is 1, blkback has a reference to the device, so > > > > userspace doesn't need to keep one. > > > > > > > > Together, these changes allow userspace to use block devices with > > > > delete-on-close behavior, such as loop devices with the autoclear flag > > > > set or device-mapper devices with the deferred-remove flag set. > > > > > > There was some work in the past to allow reloading blkback as a > > > module, it's clear that using delete-on-close won't work if attempting > > > to reload blkback. > > > > Should blkback stop itself from being unloaded if delete-on-close is in > > use? > > Hm, maybe. I guess that's the best we can do right now. I’ll implement this. > > > Isn't there some existing way to check whether a device is opened? > > > (stat syscall maybe?). > > > > Knowing that the device has been opened isn’t enough. The block script > > needs to be able to wait for blkback (and not something else) to open > > the device. Otherwise it will be confused if the device is opened by > > e.g. udev. > > Urg, no, the block script cannot wait indefinitely for blkback to open > the device, as it has an execution timeout. blkback is free to only > open the device upon guest frontend connection, and that (when using > libxl) requires the hotplug scripts execution to be finished so the > guest can be started. I’m a bit confused here. My understanding is that blkdev_get_by_dev() already opens the device, and that happens in the xenstore watch handler. I have tested this with delete-on-close device-mapper devices, and it does work. > > > I would like to avoid adding more xenstore blkback state if such > > > information can be fetched from other methods. > > > > I don’t think it can be, unless the information is passed via a > > completely different method. Maybe netlink(7) or ioctl(2)? Arguably > > this information should not be stored in Xenstore at all, as it exposes > > backend implementation details to the frontend. > > Could you maybe use sysfs for this information? Probably? This would involve adding a new file in sysfs. > We have all sorts of crap in xenstore, but it would be best if we can > see of placing stuff like this in another interface. Fair. > Thanks, Roger.
On Thu, Jun 08, 2023 at 11:11:44AM +0200, Roger Pau Monné wrote: > On Wed, Jun 07, 2023 at 12:29:26PM -0400, Demi Marie Obenour wrote: > > On Wed, Jun 07, 2023 at 10:44:48AM +0200, Roger Pau Monné wrote: > > > On Tue, Jun 06, 2023 at 01:31:25PM -0400, Demi Marie Obenour wrote: > > > > On Tue, Jun 06, 2023 at 11:15:37AM +0200, Roger Pau Monné wrote: > > > > > On Tue, May 30, 2023 at 04:31:16PM -0400, Demi Marie Obenour wrote: > > > > > > Set "opened" to "0" before the hotplug script is called. Once the > > > > > > device node has been opened, set "opened" to "1". > > > > > > > > > > > > "opened" is used exclusively by userspace. It serves two purposes: > > > > > > > > > > > > 1. It tells userspace that the diskseq Xenstore entry is supported. > > > > > > > > > > > > 2. It tells userspace that it can wait for "opened" to be set to 1. > > > > > > Once "opened" is 1, blkback has a reference to the device, so > > > > > > userspace doesn't need to keep one. > > > > > > > > > > > > Together, these changes allow userspace to use block devices with > > > > > > delete-on-close behavior, such as loop devices with the autoclear flag > > > > > > set or device-mapper devices with the deferred-remove flag set. > > > > > > > > > > There was some work in the past to allow reloading blkback as a > > > > > module, it's clear that using delete-on-close won't work if attempting > > > > > to reload blkback. > > > > > > > > Should blkback stop itself from being unloaded if delete-on-close is in > > > > use? > > > > > > Hm, maybe. I guess that's the best we can do right now. > > > > I’ll implement this. > > Let's make this a separate patch. Good idea. > > > > > Isn't there some existing way to check whether a device is opened? > > > > > (stat syscall maybe?). > > > > > > > > Knowing that the device has been opened isn’t enough. The block script > > > > needs to be able to wait for blkback (and not something else) to open > > > > the device. Otherwise it will be confused if the device is opened by > > > > e.g. udev. > > > > > > Urg, no, the block script cannot wait indefinitely for blkback to open > > > the device, as it has an execution timeout. blkback is free to only > > > open the device upon guest frontend connection, and that (when using > > > libxl) requires the hotplug scripts execution to be finished so the > > > guest can be started. > > > > I’m a bit confused here. My understanding is that blkdev_get_by_dev() > > already opens the device, and that happens in the xenstore watch > > handler. I have tested this with delete-on-close device-mapper devices, > > and it does work. > > Right, but on a very contended system there's no guarantee of when > blkback will pick up the update to "physical-device" and open the > device, so far the block script only writes the physical-device node > and exits. With the proposed change the block script will also wait > for blkback to react to the physcal-device write, hence making VM > creation slower. Only block scripts that choose to wait for device open suffer this performance penalty. My current plan is to only do so for delete-on-close devices which are managed by the block script itself. Other devices will not suffer a performance hit. In the long term, I would like to solve this problem entirely by using an ioctl to configure blkback. The ioctl would take a file descriptor argument, avoiding the need for a round-trip through xenstore. This also solves a security annoyance with the current design, which is that the device is opened by a kernel thread and so the security context of whoever requested the device to be opened is lost. > > > > > I would like to avoid adding more xenstore blkback state if such > > > > > information can be fetched from other methods. > > > > > > > > I don’t think it can be, unless the information is passed via a > > > > completely different method. Maybe netlink(7) or ioctl(2)? Arguably > > > > this information should not be stored in Xenstore at all, as it exposes > > > > backend implementation details to the frontend. > > > > > > Could you maybe use sysfs for this information? > > > > Probably? This would involve adding a new file in sysfs. > > > > > We have all sorts of crap in xenstore, but it would be best if we can > > > see of placing stuff like this in another interface. > > > > Fair. > > Let's see if that's a suitable approach, and we can avoid having to > add an extra node to xenstore. I thought about this some more and realized that in Qubes OS, we might want to include the diskseq in the information dom0 gets about each exported block device. This would allow dom0 to write the xenstore node itself, but it would require some way for dom0 to be informed about blkback having this feature.
On Thu, Jun 08, 2023 at 12:08:55PM +0200, Roger Pau Monné wrote: > On Tue, May 30, 2023 at 04:31:16PM -0400, Demi Marie Obenour wrote: > > Set "opened" to "0" before the hotplug script is called. Once the > > device node has been opened, set "opened" to "1". > > > > "opened" is used exclusively by userspace. It serves two purposes: > > > > 1. It tells userspace that the diskseq Xenstore entry is supported. > > > > 2. It tells userspace that it can wait for "opened" to be set to 1. > > Once "opened" is 1, blkback has a reference to the device, so > > userspace doesn't need to keep one. > > > > Together, these changes allow userspace to use block devices with > > delete-on-close behavior, such as loop devices with the autoclear flag > > set or device-mapper devices with the deferred-remove flag set. > > Now that I think a bit more about this, how are you planning to handle > reboot with such devices? It's fine for loop (because those get > instantiated by the block script), but likely not with other block > devices, as on reboot the toolstack will find the block device is > gone. > > I guess the delete-on-close is only intended to be used for loop > devices? (or in general block devices that are instantiated by the > block script itself) You understand correctly.
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 9c3eb148fbd802c74e626c3d7bcd69dcb09bd921..519a78aa9073d1faa1dce5c1b36e95ae58da534b 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -3,6 +3,20 @@ Copyright (C) 2005 Rusty Russell <rusty@rustcorp.com.au> Copyright (C) 2005 XenSource Ltd +In addition to the Xenstore nodes required by the Xen block device +specification, this implementation of blkback uses a new Xenstore +node: "opened". blkback sets "opened" to "0" before the hotplug script +is called. Once the device node has been opened, blkback sets "opened" +to "1". + +"opened" is read exclusively by userspace. It serves two purposes: + +1. It tells userspace that diskseq@major:minor syntax for "physical-device" is + supported. + +2. It tells userspace that it can wait for "opened" to be set to 1 after writing + "physical-device". Once "opened" is 1, blkback has a reference to the + device, so userspace doesn't need to keep one. */ @@ -699,6 +713,14 @@ static int xen_blkbk_probe(struct xenbus_device *dev, if (err) pr_warn("%s write out 'max-ring-page-order' failed\n", __func__); + /* + * This informs userspace that the "opened" node will be set to "1" when + * the device has been opened successfully. + */ + err = xenbus_write(XBT_NIL, dev->nodename, "opened", "0"); + if (err) + goto fail; + err = xenbus_switch_state(dev, XenbusStateInitWait); if (err) goto fail; @@ -826,6 +848,19 @@ static void backend_changed(struct xenbus_watch *watch, goto fail; } + /* + * Tell userspace that the device has been opened and that blkback has a + * reference to it. Userspace can then close the device or mark it as + * delete-on-close, knowing that blkback will keep the device open as + * long as necessary. + */ + err = xenbus_write(XBT_NIL, dev->nodename, "opened", "1"); + if (err) { + xenbus_dev_fatal(dev, err, "%s: notifying userspace device has been opened", + dev->nodename); + goto free_vbd; + } + err = xenvbd_sysfs_addif(dev); if (err) { xenbus_dev_fatal(dev, err, "creating sysfs entries");