From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Block Mailing List <linux-block@vger.kernel.org>,
Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Race-free block device opening
Date: Tue, 26 Apr 2022 14:12:22 -0400 [thread overview]
Message-ID: <Ymg2HIc8NGraPNbM@itl-email> (raw)
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
Right now, opening block devices in a race-free way is incredibly hard.
The only reasonable approach I know of is sd_device_new_from_path() +
sd_device_open(), and is only available in systemd git main. It also
requires waiting on systemd-udev to have processed udev rules, which can
be a bottleneck. There are better approaches in various special cases,
such as using device-mapper ioctls to check that the device one has
opened still has the name and/or UUID one expects. However, none of
them works for a plain call to open(2).
A much better approach would be for udev to point its symlinks at
"/dev/disk/by-diskseq/$DISKSEQ" for non-partition disk devices, or at
"/dev/disk/by-diskseq/${DISKSEQ}p${PARTITION}" for partitions. A
filesystem would then be mounted at "/dev/disk/by-diskseq" that provides
for race-free opening of these paths. This could be implemented in
userspace using FUSE, either with difficulty using the current kernel
API, or easily and efficiently using a new kernel API for opening a
block device by diskseq + partition. However, I think this should be
handled by the Linux kernel itself.
What would be necessary to get this into the kernel? I would like to
implement this, but I don’t have the time to do so anytime soon. Is
anyone else interested in taking this on? I suspect the kernel code
needed to implement this would be quite a bit smaller than the FUSE
implementation.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2022-04-26 18:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 18:12 Demi Marie Obenour [this message]
2022-04-26 18:35 ` Race-free block device opening Greg Kroah-Hartman
2022-04-26 21:31 ` Demi Marie Obenour
2022-04-26 22:07 ` Demi Marie Obenour
2022-04-27 13:29 ` James Bottomley
2022-05-07 11:35 ` Demi Marie Obenour
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=Ymg2HIc8NGraPNbM@itl-email \
--to=demi@invisiblethingslab.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.