[RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-- 
2.43.2





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux