On Sun, Jun 25, 2023 at 06:33:33PM +0200, Milan Broz wrote: > On 6/25/23 18:02, Demi Marie Obenour wrote: > > On Sun, Jun 25, 2023 at 03:25:38PM +0200, Milan Broz wrote: > > > On 6/25/23 01:09, Demi Marie Obenour wrote: > > > > Userspace can use this to avoid spamming udev with events that udev > > > > should ignore. > > > > > > Well, does it also mean that udev will not create /dev/disk/by-* symlinks > > > (as response to the change udev event followed by internal udev blkid scan)? > > > > In the use-case I have for this feature (block devices for Qubes VMs) > > the blkid scan is unwanted and there are udev rules to prevent this. > > > > > If it is a private device, that is ok. But for a visible device I think > > > that it breaks some assumptions in userspace (presence of symlinks mentioned > > > above etc). > > > > The devices I am considering are implementation details of a userspace > > process. Nobody else should be opening them. Ideally, no other > > userspace process would even know they exist, at least without mucking > > around in /proc or using ptrace. > > > > > So, what is the exact use for this patch? > > > > Ephemeral devices that are created, opened, marked for deferred removal, > > assigned to a Xen VM (needs another patch currently being worked on), > > and then closed. udev has no business scanning these devices, and > > indeed for it to scan them at all would be a security vulnerability > > since their contents are under guest control. There are udev rules to > > ignore these devices, but for udev to even process the event wastes CPU > > time and delays processing of other events that actually matter. The > > only symlink that possibly ought to be created is /dev/disk/by-diskseq > > and I can just do that myself. > But this is not clear from the patch header. I guess you also need > to disable udev inotify on close on write, which will trigger device scan too. > > BTW we use exactly this scenario in cryptsetup for years with existing flags > (DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG | DM_UDEV_DISABLE_DISK_RULES_FLAG > DM_UDEV_DISABLE_OTHER_RULES_FLAG) - just rules are ignored while uevent is still > sent. > Anyway, not sure we need another way to disable it; I just asked do you need it. How can one set these flags using the raw kernel ioctls? The code I am working on does not use libdevmapper at all and just uses the kernel API directly. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
