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

My apologies for not using plain text mode.


On Tue, May 13, 2025 at 4:08 PM Chengen Du <[email protected]> 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.
> The issue concerns a potential hang during the boot process when the system is waiting for the encrypted swap device node.
> This is caused by systemd-makefs skipping block device access locking for device-mapper devices.
>
> A more detailed explanation and proposed solution are documented here [2].
>
> In brief, systemd-udevd probes block devices for filesystem superblock and partition table information as they appear.
> If another process modifies a superblock or partition table concurrently, the probing can be affected.
> This, in turn, may lead to unintended behavior in programs that rely on udev events.
>
> 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.
>
> The commit appears somewhat ambiguous to me, as my understanding is that device-mapper devices should not be deactivated while a udev rule is being processed.
> I’ve reached out to the original author for clarification but haven’t received a response yet.
> I’ve also reviewed related projects such as multipath-tools and lvm2, but couldn’t find similar examples of deactivating devices during udev remove events.
>
> As I may not be an expert in this specific area, I would greatly appreciate it if you could share your insights on the matter.
> In particular, could you help confirm whether holding a flock lock on a block device while handling udev events might introduce any regressions?
> If this issue falls outside your scope, please kindly disregard this message—and I apologize for the disturbance.
>
> Since the bug is related to a boot hang, we are eager to resolve it promptly.
> Please don’t hesitate to raise any concerns or suggestions.
>
> Thank you very much for your support.
>
> Best regards,
> Chengen Du
>
> [1] https://github.com/systemd/systemd/pull/37080
> [2] https://github.com/systemd/systemd/blob/main/docs/BLOCK_DEVICE_LOCKING.md