Feedback-ID: iac594737:Fastmail
Date:   Tue, 31 Jan 2023 11:27:59 -0500
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Jens Axboe <axboe@kernel.dk>,
        Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
        <marmarek@invisiblethingslab.com>, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/7] block: Support creating a struct file from a
 block device
Message-ID: <Y9lBlKD3U/jMug9j@itl-email>
References: <20230126033358.1880-1-demi@invisiblethingslab.com>
 <20230126033358.1880-2-demi@invisiblethingslab.com>
 <Y9d692WEX/ZvBhXI@infradead.org>
 <Y9gZAJGgdjFtsm9I@itl-email>
 <Y9jW73uAtE3HdCou@infradead.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="xiaE+CeULPiwBElu"
Content-Disposition: inline
In-Reply-To: <Y9jW73uAtE3HdCou@infradead.org>
Precedence: bulk


--xiaE+CeULPiwBElu
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Jan 2023 11:27:59 -0500
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/7] block: Support creating a struct file from a
 block device

On Tue, Jan 31, 2023 at 12:53:03AM -0800, Christoph Hellwig wrote:
> On Mon, Jan 30, 2023 at 02:22:39PM -0500, Demi Marie Obenour wrote:
> > What do you recommend instead?  This solves a real problem for
> > device-mapper users and I am not aware of a better solution.
>=20
> You could start with explaining the problem and what other methods
> you tried that failed.  In the end it's not my job to fix your problem.

I=E2=80=99m working on a =E2=80=9Cblock not-script=E2=80=9D (Xen block devi=
ce hotplug script
written in C) for Qubes OS.  The current hotplug script is a shell
script that takes a global lock, which serializes all invocations and
significantly slows down VM creation and destruction.  My C program
avoids this problem.

One of the goals of the not-script is to never leak resources, even if
it dies with SIGKILL or is never called with the =E2=80=9Cremove=E2=80=9D a=
rgument to
destroy the devices it created.  Therefore, whenever possible, it relies
on automatic destruction of devices that are no longer used.  I have
managed to make this work for loop devices, provided that the Xen
blkback driver is patched to accept a diskseq in the physical-device
Xenstore node.  I have *not* managed to make this work for device-mapper
devices, however.  One of the problems is that there is no way to
atomically create a device-mapper device and obtain a file descriptor to
it such that the device will be destroyed when no longer used.  To solve
this problem, I added a new flag (DM_FILE_DESCRIPTOR_FLAG) that asks the
device-mapper driver to provide userspace a file descriptor for the
device that was just created.  The uAPI will likely change in future
versions of the patch, but the general idea will not.

While it is easy to provide userspace with an FD to any struct file, it
is *not* easy to obtain a struct file for a given struct block_device.
I could have had device-mapper implement everything itself, but that
would have duplicated a large amount of code already in the block layer.
Instead, I decided to refactor the block layer to provide a function
that does exactly what was needed.  The result was this patch.  In the
future, I would like to add an ioctl for /dev/loop-control that creates
a loop device and returns a file descriptor to the loop device.  I could
also see iSCSI supporting this, with the socket file descriptor being
passed in from userspace.

blkdev_do_open() does not solve any problem for me at this time.
Instead, it represents the code shared by blkdev_get_by_dev() and
blkdev_get_file().  I decided to export it because it could be of
independent use to others.  In particular, it could potentially
simplify disk_scan_partitions() in block/genhd.c, pkt_new_dev() in
pktcdvd, backing_dev_store() in zram, and f2fs_scan_devices() in f2fs.

I hope this is enough information.  If it is not, feel free to ask for
more.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--xiaE+CeULPiwBElu
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmPZQZQACgkQsoi1X/+c
IsGBEw/8Cdl16B9BaBXFp256DXyCZMehNStQ1CM3Fho/OkTAAfFMQIz3Yn17xNQG
88JihQ6BxaiQyNojeOLxTfK6omkPfN410l8tKDlWUHtlsPiOD73FqdUH8JSpeR3q
f4HD1jXsvqNqi1Adgf1sxGs49YE+t5sEntp0Dv03na9PCO1xW4dNGCG/WG1OsjrF
EQSmw8FnedvVjG0ZAthVwoNkIW97yJsLOHEOu94Ot6zprG+b9yh1d3haWBo4oOic
2pWkIWGtPAb+m4vcSW9tmYF6tfQvkpFwAXiiVIoRmzucq2qoi+0eboWCBvNllrsE
WFMskiS2MQaiLzs6id1FZKbnjACld6txGRvF3TtjW7gZiQoC87SC0l8vlz/wH4VY
jZ/lCstFWznAz5sjqDiNvBFufJ9hbcLHVNjpfCdpUIXaSGhRgqv4vHAbFwa6aMMC
TS/xEMJQeN6N4yAuvD1x5u4ghY5BmaLFc6c8jsJ82IgW/hWLvBVcvbIxOsKtVyzF
ftbYXQ5uFBg6oRc3eqM3SgZbdwDkJA5Qfb0FS1RV54BJjQG0HX/LEVwOBHhOmnxT
xr5hBwxdgUcIO4a0s+4aunb5PmBAbe0Xk58h+3aYz9qmNFrJtm+LPmbNt6BmW0U1
XPVNEeXwo7XEKN7+/C8YByEn43ndlD0A+R8L2iKk94+w7QAoSio=
=ldQE
-----END PGP SIGNATURE-----

--xiaE+CeULPiwBElu--