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@xxxxxxxx>
> ---
> 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
