Hi Zdenek, Thank you for your feedback on this issue. Your input has been valuable in moving the discussion forward.
On Wed, Jun 4, 2025 at 5:06 PM Zdenek Kabelac <zkabe...@redhat.com> wrote: > > Dne 04. 06. 25 v 5:33 Chengen Du napsal(a): > > Hi DM developers, > > > > On Tue, May 13, 2025 at 10:35 PM Lennart Poettering > > <lenn...@poettering.net> wrote: > >> > >> On Di, 13.05.25 16:08, Chengen Du (chengen...@canonical.com) wrote: > >> > >>> Hi, > >>> > >>> Apologies for including everyone in this message, but I’d like to bring > >>> your attention to a fix [1], which may require your input. > >> > >> As mentioned in my comments there: we can certainly enable the locking > >> stuff again for DM block devices too, but only if DM maintainers sign > >> off that this is OK. Hence ping the DM people about this, otherwise we > >> won't move on this. > >> > >>> To mitigate such issues, systemd-udevd normally acquires a LOCK_SH|LOCK_NB > >>> using flock on the main block device before processing. > >>> However, commit #e918a1b5a94f (udev: exclude device-mapper from block > >>> device ownership event locking) disabled this behavior for device-mapper > >>> devices, which appears to be the root cause of the boot hang with > >>> encrypted > >>> swap. > >> > >> iirc dm for some reason is allergic to us taking a bsd lock, because > >> they don't want us to hold an fd open while the udev rules run > >> (because bsd locking implies holding an fd open as long as the lock is > >> kept). > >> > >> But only the DM people can shed some light on this. if they are fine > >> these days if we relax this then we can certainly cover their stuff > >> via the locking, too. > > > > Apologies for reaching out again, but may I kindly ask for your input > > on this issue? > > Your assistance would be greatly appreciated to help move things forward. > > > Hi > > We have overlooked the issue which seems to have origins most likely in the > lost uevents due to switch from initramfs to rootfs and should be possibly > addressed by a new socket flag. > > But anyway let's looks at the current locking mechanism. > > So for lvm2 to be able to 'deactivate' DM device - such device must NOT be > opened - so taking a lock on an open descriptor to deactivate DM device is > likely not going to work. > > lvm2 however could be possibly enhanced to at least grab these bsd locks maybe > when processing PV - that does not looks like a problematic part. > > But adding bsd locks when processing DM (active LVs) looks like not so > trivial task - there are DM devices which are 'private' to DM stack itself > (i.e. cached raid LV - for a single public DM device - there might be > tens of 'private' DM devices associated in a device tree - and for none of > these devices lvm2 expects anyone using them - so any 'device stack tree' > manipulation basically aborts when an unexpected user is there (public > availability of these 'private' devices is however useful thing for various > 'recovery/debugging' reasons - so there is very good reason all devices are > present in users's /dev/ directory - but administrator should not blindly open > them) > > For protection against udev access to these private devices - were have > originally used some uevent flags - those however were not 'permanent' as if > udev was restarted with the clear database - all this info was lost (like one > of the reason we asked in the past for this DM exception). Later on we added > UUID -suffix solution - but this is not yet 'decorating' all device types - > and although we now try to add them - it's not a simple task - so likely some > nearby future version of lvm2 could be better - and in such a case - if this > newer version of lvm2 would be in the system - and there would be no access > to any device with UUID '-suffix' from udev tools chain - we can possibly > reconsider this DM exception and see whether we can make it work somehow. > > Yet - for locking itself - I'd probably see some usage of separate locking dir > in /run as more usable approach - as the case where device needs to be > 'removed/instantiated/....' cannot be 'lock protected' if the device itself > must be held open. I actually considered this approach earlier. We could achieve the same goal by introducing a file under the /run directory and using it as a target for flock. One potential challenge might be reaching consensus on the file name format. While this method may not be as straightforward as using the main block device, it could help address the issue of deactivating a block device that's being held open. I'm not an expert in this area, so perhaps Lennart could provide more informed insights. > > But as a short term solution - we would rather need to see the actual exact > problem which seems to be missing this locking - as is could be possibly > something unrelated to this locking... The issue we're aiming to resolve currently lies within systemd. During the boot process, the system may hang while waiting for the encrypted swap device node. This appears to be caused by the absence of block device access locking for device-mapper devices during udev event processing. This problem could potentially be addressed by reintroducing locking during udev processing, as systemd already wraps operations using systemd-makefs, which implements the necessary locking logic. I understand that additional work may be required on the lvm2 side before block device access locking can be fully considered. One of the main concerns with this proposed fix is that the main device may be opened if a BSD lock is held during udev processing. > > > Regards > > Zdenek >
