DISK_RO is set in the environment of a block-device uevent if and only if
the read-only (ro) attribute of the device just changed (the kernel
function set_disk_ro() was called). It is not synoymous with the "ro" sysfs
attribute; the device could very well be write-protected if DISK_RO is not
set. Device mapper-level probing is possible for DISK_RO events, but it makes
little sense, because the device propreties haven't changed as far as dm is
concerned. But we should import possible previously set device properties
to avoid confusing follow-up rules. We should do this for both DISK_RO=1
and DISK_RO=0 events.
Signed-off-by: Martin Wilck <mwilck@xxxxxxxx>
---
udev/10-dm.rules.in | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/udev/10-dm.rules.in b/udev/10-dm.rules.in
index 4ffd3e2..f83fbec 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
@@ -69,6 +66,10 @@ IMPORT{db}="DM_UDEV_FLAG7"
IMPORT{db}="DM_UDEV_RULES_VSN"
LABEL="dm_flags_done"
+# If DISK_RO is set, it's an uevent that changes the ro attribute of the device.
+# The event should be ignored as far as dm is concerned.
+ENV{DISK_RO}=="0|1", GOTO="dm_disable"
+
# Normally, we operate on "change" events. But when coldplugging, there's an
# "add" event present. We have to recognize this and do our actions in this
# particular situation, too. Also, we don't want the nodes to be created
--
2.43.2
