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;
Feedback-ID: iac594737:Fastmail
Date:   Wed, 7 Jun 2023 12:29:26 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Cc:     Jens Axboe <axboe@kernel.dk>, Alasdair Kergon <agk@redhat.com>,
        Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com,
        Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
        <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
Message-ID: <ZICwaWidZxhaGp8v@itl-email>
References: <20230530203116.2008-1-demi@invisiblethingslab.com>
 <20230530203116.2008-17-demi@invisiblethingslab.com>
 <ZH75OTMA6N3zYrH2@Air-de-Roger>
 <ZH9tcGh0N2fEcwjH@itl-email>
 <ZIBDgKKDhDj+//Q0@Air-de-Roger>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="T6W25fvao3OB3Dc6"
Content-Disposition: inline
In-Reply-To: <ZIBDgKKDhDj+//Q0@Air-de-Roger>
Precedence: bulk


--T6W25fvao3OB3Dc6
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Jun 2023 12:29:26 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>, Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <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

On Wed, Jun 07, 2023 at 10:44:48AM +0200, Roger Pau Monn=C3=A9 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=C3=A9 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".
> > > >=20
> > > > "opened" is used exclusively by userspace.  It serves two purposes:
> > > >=20
> > > > 1. It tells userspace that the diskseq Xenstore entry is supported.
> > > >=20
> > > > 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.
> > > >=20
> > > > Together, these changes allow userspace to use block devices with
> > > > delete-on-close behavior, such as loop devices with the autoclear f=
lag
> > > > set or device-mapper devices with the deferred-remove flag set.
> > >=20
> > > 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.
> >=20
> > Should blkback stop itself from being unloaded if delete-on-close is in
> > use?
>=20
> Hm, maybe.  I guess that's the best we can do right now.

I=E2=80=99ll implement this.

> > > Isn't there some existing way to check whether a device is opened?
> > > (stat syscall maybe?).
> >=20
> > Knowing that the device has been opened isn=E2=80=99t enough.  The bloc=
k 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.
>=20
> 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=E2=80=99m a bit confused here.  My understanding is that blkdev_get_by_de=
v()
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.
> >=20
> > I don=E2=80=99t 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.
>=20
> 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.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--T6W25fvao3OB3Dc6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSAsGoACgkQsoi1X/+c
IsEv9xAAh+0oREoh82YjIN1bf0M1x4FiXf8Db1W1nyF5Mx6GR8TSALA4UdBF2ZhR
wBwIpZKAJBxV5wW48ABeWatkop35EaE8V3Ort7gf5IeOoX4f13W3KiPPEO49b6Ar
hEdL93rM4XH4bNxeXAYh7OUi2of/zjJl+n4IOVV8Bl0c5WL65J+H4yQ+6VQdcsgr
K1DBOJgLy1ljc7MJWQHW44MFVvx4DE84BjTO1fuAZzrQ7OG3EvGh6f0WcodtzZk9
gfaSAv1c98EZcihrdaHl0NDxgybr8BZug+L1xq9so8+z5Kywi98TMOqd20pGwJkX
sALzQMVV/0gdWv1pXVxH/c8RO3RO0+eZoCS/N0/a3Ae/EldhlO8DKZ8UXq+vJ1V7
L4eGvdfBU1oqTKTXq5jekUTPF66oaW9TEFYTkW64n/hWRdFiRG8PEoglMC5YZB9G
yrCgqCdHPDHtG3TEPE0p1HqF9DFGffIE/OGhzEXvx0UXdVdB+J8oZa+G9W2yaKMZ
kuyC54J0FhOMkRFodoGgkpWnxpiC6mJMHnlEdpeSxWI41elg3jvH9MkHVOL9sTrr
bSQnmjwNBlxMlsbjo9Li6vzinnLNvwQR2LGT0t9vk7GFBI9wa0LWMReyO3mzz5c8
E5/g1pRZo3Jw/n/FWdQfdWiQQ3T4KSmHuV4ddrApHwIhrnl6WAg=
=I2t4
-----END PGP SIGNATURE-----

--T6W25fvao3OB3Dc6--