linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
	"Alasdair Kergon" <agk@redhat.com>,
	"Mike Snitzer" <snitzer@kernel.org>,
	dm-devel@redhat.com,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 16/16] xen-blkback: Inform userspace that device has been opened
Date: Wed, 7 Jun 2023 10:44:48 +0200	[thread overview]
Message-ID: <ZIBDgKKDhDj+//Q0@Air-de-Roger> (raw)
In-Reply-To: <ZH9tcGh0N2fEcwjH@itl-email>

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.

> > 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 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?

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.

Thanks, Roger.

  reply	other threads:[~2023-06-07  8:45 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 20:31 [PATCH v2 00/16] Diskseq support in loop, device-mapper, and blkback Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 01/16] device-mapper: Check that target specs are sufficiently aligned Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 02/16] device-mapper: Avoid pointer arithmetic overflow Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 03/16] device-mapper: do not allow targets to overlap 'struct dm_ioctl' Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 04/16] device-mapper: Better error message for too-short target spec Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 05/16] device-mapper: Target parameters must not overlap next " Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 06/16] device-mapper: Avoid double-fetch of version Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 07/16] device-mapper: Allow userspace to opt-in to strict parameter checks Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 08/16] device-mapper: Allow userspace to provide expected diskseq Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 09/16] device-mapper: Allow userspace to suppress uevent generation Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 10/16] device-mapper: Refuse to create device named "control" Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 11/16] device-mapper: "." and ".." are not valid symlink names Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 12/16] device-mapper: inform caller about already-existing device Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 13/16] xen-blkback: Implement diskseq checks Demi Marie Obenour
2023-06-06  8:25   ` Roger Pau Monné
2023-06-06 17:01     ` Demi Marie Obenour
2023-06-07  8:20       ` Roger Pau Monné
2023-06-07 16:14         ` Demi Marie Obenour
2023-06-08  8:29           ` Roger Pau Monné
2023-06-08 15:33             ` Demi Marie Obenour
2023-06-09 15:13               ` Roger Pau Monné
2023-06-09 16:55                 ` Demi Marie Obenour
2023-06-12  8:09                   ` Roger Pau Monné
2023-06-21  1:14                     ` Demi Marie Obenour
2023-06-21 10:07                       ` Roger Pau Monné
2023-05-30 20:31 ` [PATCH v2 14/16] block, loop: Increment diskseq when releasing a loop device Demi Marie Obenour
2023-05-30 20:31 ` [PATCH v2 15/16] xen-blkback: Minor cleanups Demi Marie Obenour
2023-06-06  8:36   ` Roger Pau Monné
2023-05-30 20:31 ` [PATCH v2 16/16] xen-blkback: Inform userspace that device has been opened Demi Marie Obenour
2023-06-06  9:15   ` Roger Pau Monné
2023-06-06 17:31     ` Demi Marie Obenour
2023-06-07  8:44       ` Roger Pau Monné [this message]
2023-06-07 16:29         ` Demi Marie Obenour
2023-06-08  9:11           ` Roger Pau Monné
2023-06-08 15:23             ` Demi Marie Obenour
2023-06-08 10:08   ` Roger Pau Monné
2023-06-08 15:24     ` Demi Marie Obenour
2023-05-31 13:06 ` [dm-devel] [PATCH v2 00/16] Diskseq support in loop, device-mapper, and blkback Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZIBDgKKDhDj+//Q0@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=demi@invisiblethingslab.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=snitzer@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).