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. Best regards, Chengen Du > > Lennart > > -- > Lennart Poettering, Berlin
