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 <[email protected]>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.
