From: Peter Rajnoha <prajnoha@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>,
Zdenek Kabelac <zkabelac@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
David Teigland <teigland@redhat.com>
Cc: linux-lvm@lists.linux.dev, dm-devel@lists.linux.dev,
Martin Wilck <mwilck@suse.com>, Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1
Date: Mon, 4 Mar 2024 11:48:38 +0100 [thread overview]
Message-ID: <b884374b-2f6f-4c7f-acba-b4c730ae03ff@redhat.com> (raw)
In-Reply-To: <20240301224011.11117-3-mwilck@suse.com>
On 3/1/24 23:40, Martin Wilck wrote:
> DISK_RO=1 is set in the environment of a block-device uevent if and only if
> the device has just been set read-only by a driver by calling set_disk_ro().
> It is not synoymous with the "ro" sysfs attribute; the device could very well
> be write-protected if DISK_RO is not set. Probing should be possible even if
> this flag is set, because blkid and friends usually don't write to the
> device. Upper-layer subsystems that do need to write would need to check the
> "ro" sysfs attribute rather than DISK_RO.
>
> Skip the DISK_RO check in 10-dm.rules.
>
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> udev/10-dm.rules.in | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/udev/10-dm.rules.in b/udev/10-dm.rules.in
> index 4ffd3e2..c08d829 100644
> --- a/udev/10-dm.rules.in
> +++ b/udev/10-dm.rules.in
> @@ -50,9 +50,6 @@ ACTION!="add|change", GOTO="dm_end"
> # kernels >= 2.6.31 only. Cookie is not decoded for remove event.
> ENV{DM_COOKIE}=="?*", IMPORT{program}="(DM_EXEC)/dmsetup udevflags $env{DM_COOKIE}"
>
> -# Rule out easy-to-detect inappropriate events first.
> -ENV{DISK_RO}=="1", GOTO="dm_disable"
> -
> # There is no cookie set nor any flags encoded in events not originating
> # in libdevmapper so we need to detect this and try to behave correctly.
> # For such spurious events, regenerate all flags from current udev database content
Yes, I'd like to get rid of this rule, but, unfortunately, there's one
issue during the DM device creation/activation.
For example, if I try:
dmsetup create --readonly --table "0 1 zero"
Then I get these uevents:
1)
ACTION=add
DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
SYSTEMD_READY=0
2)
ACTION=change
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_DISABLE_OTHER_RULES_FLAG=
3)
ACTION=change
DM_COOKIE=6335392
DM_COOKIE_DISABLE_OTHER_RULES_FLAG=
The uevent 3) coming with the DM_COOKIE is the actual event when the
device is ready for use (that's the uevent notifying the DM device
resume/activation).
If we remove the DISK_RO rule, then the DM_UDEV_DISABLE_OTHER_RULES_FLAG
is unset for uevent 2), which in turn causes the SYSTEMD_READY=0 to get
dropped, which in turn will start all the systemd hooks because the
device is considered "ready" for systemd then.
But the DM dev is ready only after uevent 3) that comes with the
DM_COOKIE. So we still need to cover this scenario.
--
Peter
next prev parent reply other threads:[~2024-03-04 10:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 22:40 [RFC PATCH 0/7] device mapper udev rules rework Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 1/7] 13-dm-disk.rules: import ID_FS_TYPE Martin Wilck
2024-03-04 10:37 ` Peter Rajnoha
2024-03-04 15:17 ` Martin Wilck
2024-03-04 15:44 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1 Martin Wilck
2024-03-04 10:48 ` Peter Rajnoha [this message]
2024-03-04 11:19 ` Peter Rajnoha
2024-03-04 11:27 ` Peter Rajnoha
2024-03-04 15:21 ` Martin Wilck
2024-03-04 16:09 ` Martin Wilck
2024-03-05 8:09 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 3/7] 10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db Martin Wilck
2024-03-04 10:49 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 4/7] 11-dm-lvm.rules: " Martin Wilck
2024-03-04 10:51 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 5/7] dm udev rules: don't export and save DM_SUSPENDED Martin Wilck
2024-03-04 11:00 ` Peter Rajnoha
2024-03-04 16:21 ` Martin Wilck
2024-03-05 8:19 ` Peter Rajnoha
2024-03-05 8:47 ` Martin Wilck
2024-03-05 9:10 ` Peter Rajnoha
2024-03-05 9:28 ` Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 6/7] dm udev rules: don't export and save DM_NOSCAN Martin Wilck
2024-03-04 11:03 ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3 Martin Wilck
2024-03-04 11:09 ` Peter Rajnoha
2024-03-04 16:46 ` Martin Wilck
2024-03-05 8:26 ` Peter Rajnoha
2024-03-05 9:04 ` Martin Wilck
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=b884374b-2f6f-4c7f-acba-b4c730ae03ff@redhat.com \
--to=prajnoha@redhat.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
--cc=linux-lvm@lists.linux.dev \
--cc=martin.wilck@suse.com \
--cc=mwilck@suse.com \
--cc=teigland@redhat.com \
--cc=zkabelac@redhat.com \
/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).