From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
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: Re: Race-free block device opening
Date: Tue, 26 Apr 2022 20:35:34 +0200 [thread overview]
Message-ID: <Ymg7dihxLG923vs3@kroah.com> (raw)
In-Reply-To: <Ymg2HIc8NGraPNbM@itl-email>
On Tue, Apr 26, 2022 at 02:12:22PM -0400, Demi Marie Obenour wrote:
> 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).
Why do you call open(2) on a block device?
> 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.
You can do that today with udev rules, right?
> A
> filesystem would then be mounted at "/dev/disk/by-diskseq" that provides
> for race-free opening of these paths.
How would it be any less race-free than just open("/dev/sda1") is?
> 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?
Get what exactly? I don't see anything the kernel needs to do here
specifically. Normally block devices are accessed using mount(2), not
open(2). Do you want a new mount(2)-type api?
thanks,
greg k-h
next prev parent reply other threads:[~2022-04-26 18:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 18:12 Race-free block device opening Demi Marie Obenour
2022-04-26 18:35 ` Greg Kroah-Hartman [this message]
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=Ymg7dihxLG923vs3@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=demi@invisiblethingslab.com \
--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.