From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>,
dm-devel@lists.linux.dev
Subject: Re: [PATCH] 11-dm-mpath.rules: fix misspelled DM_UDEV_DISABLE_OTHER_RULES_FLAG
Date: Fri, 01 Mar 2024 20:20:12 +0100 [thread overview]
Message-ID: <ce5f750bced0598771a44c8a61520db607703ba8.camel@suse.com> (raw)
In-Reply-To: <ZeIbYETl5FIvfNxA@bmarzins-01.fast.eng.rdu2.dc.redhat.com>
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@redhat.com>
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.
prev parent reply other threads:[~2024-03-01 19:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 17:25 [PATCH] 11-dm-mpath.rules: fix misspelled DM_UDEV_DISABLE_OTHER_RULES_FLAG Martin Wilck
2024-03-01 18:16 ` Benjamin Marzinski
2024-03-01 19:20 ` Martin Wilck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce5f750bced0598771a44c8a61520db607703ba8.camel@suse.com \
--to=mwilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).