Re: [systemd-devel] [Discussion][device-mapper] Enabling Block Device Access Locking in systemd

On Fri, Jun 6, 2025 at 12:18=E2=80=AFPM Chengen Du <[email protected]=
m> wrote:
>
> 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=E2=80=AFPM Zdenek Kabelac <[email protected]=
m> wrote:
> >
> > Dne 04. 06. 25 v 5:33 Chengen Du napsal(a):
> > > Hi DM developers,
> > >
> > > On Tue, May 13, 2025 at 10:35=E2=80=AFPM Lennart Poettering
> > > <[email protected]> wrote:
> > >>
> > >> On Di, 13.05.25 16:08, Chengen Du ([email protected]) wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Apologies for including everyone in this message, but I=E2=80=99d l=
ike to bring
> > >>> your attention to a fix [1], which may require your input.
> > >>
> > >> As mentioned in my comments there: we can certainly enable the locki=
ng
> > >> stuff again for DM block devices too, but only if DM maintainers sig=
n
> > >> 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 blo=
ck
> > >>> device ownership event locking) disabled this behavior for device-m=
apper
> > >>> devices, which appears to be the root cause of the boot hang with e=
ncrypted
> > >>> 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 forw=
ard.
> >
> >
> > 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 possi=
bly
> > 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 lock=
s 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 it=
self
> > (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 tre=
e'
> > manipulation basically aborts when an unexpected user is there  (public
> > availability of these 'private' devices is however useful thing for var=
ious
> > 'recovery/debugging' reasons - so there is very good reason all devices=
 are
> > present in users's /dev/ directory - but administrator should not blind=
ly 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  (l=
ike 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 typ=
es -
> > and although we now try to add them - it's not a simple task - so likel=
y 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 a=
ccess
> > to any device with UUID '-suffix' from udev tools chain - we can possib=
ly
> > reconsider this DM exception and see whether we can make it work someho=
w.
> >
> > Yet - for locking itself - I'd probably see some usage of separate lock=
ing dir
> > in /run  as more usable approach - as the case where device needs to be
> > 'removed/instantiated/....' cannot be 'lock protected' if the device it=
self
> > 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 form=
at.
> 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.

Hi Lennart, would you mind sharing your thoughts on this? I believe
this could be a viable approach to achieve the same goal while also
avoiding the need to keep a block device open unnecessarily.

>
> >
> > But as a short term solution - we would rather need to see the actual e=
xact
> > problem which seems to be missing this locking - as is could be possibl=
y
> > 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.

Hi Device Mapper maintainers, I=E2=80=99ve elaborated further on our
adjustments in this email. Please note that I=E2=80=99m not requesting the
adoption of block device access locking at this stage, as I understand
there may still be some preparatory work required. Instead, I=E2=80=99d
appreciate your confirmation on whether it is acceptable for us to
acquire a flock on a block device while handling udev events. This may
cause the block device's open count to become one.

>
> >
> >
> > Regards
> >
> > Zdenek
> >