On Fri, 2024-03-01 at 13:16 -0500, Benjamin Marzinski wrote:
> On Fri, Mar 01, 2024 at 06:25:14PM +0100, Martin Wilck wrote:
> > Fixes: b3582da ("11-dm-mpath.rules: use import logic like 13-dm-
> > disk.rules")
> Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Thanks for the quick review, Ben!
FTR: While this is an embarrassing bug in 0.9.8, I think it's real
impact is rather low.
First of all, it's not regression wrt earlier releases, because these
releases didn't check DM_UDEV_DISABLE_OTHER_RULES_FLAG at this point in
the code in the first place.
Secondly, the bug matters only for multipath devices that
- have at least one valid path,
- and have been probed successfully by upper layers before,
- and are suspended at the time the uevent is processed [1].
In this case, some udev properties will be missing in later rules
because we mistakenly don't import them from the db. For systems with
recent lvm2 (2.03.19 and later), only ID_FS_TYPE and ID_FS_VERSION will
be missing, as the other properties will be imported by 13-dm-
disk.rules later; on systems with older lvm2 releases all blkid-derived
properties will be missing.
ID_FS_TYPE is an important property. Yet no subsystem I am aware of
will destroy an already set-up block device stack because ID_FS_TYPE
isn't set any more. AFAIK the only entity that attempts to destroy
existing layers is systemd, which does this if it encounters
SYSTEMD_READY=0 for a previously activated device. But this does not
happen for suspended devices.
In other words, properties like ID_FS_TYPE will be missing after
processing an uevent on a suspended device, but that should do no
actual harm to the system. When the device is resumed, an uevent will
be generated and the missing properties will be reinstated.
Martin
[1] because for dm-multipath, DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
essentially means that the device is suspended.
