Blame SOURCES/0083-multipath.rules-fix-smart-bug-with-failed-valid-path.patch

e71b65
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
e71b65
From: Benjamin Marzinski <bmarzins@redhat.com>
e71b65
Date: Tue, 7 Feb 2023 15:39:26 -0600
e71b65
Subject: [PATCH] multipath.rules: fix "smart" bug with failed valid path check
e71b65
e71b65
If "multipath -u" fails, udev doesn't import any values from the
e71b65
program. This means that multipath.rules will continue to use the values
e71b65
for DM_MULTIPATH_DEVICE_PATH and FIND_MULTIPATHS_WAIT_UNTIL that it has
e71b65
already imported from the database. This is the correct thing to do for
e71b65
every case except the MAYBE case for "find_multipaths smart". In that
e71b65
case, DM_MULTIPATH_DEVICE_PATH will be set to 1, and the rules will
e71b65
assume that the device has been definitively claimed.
e71b65
e71b65
In this case, we know that the device shouldn't have been claimed
e71b65
before, but we don't know if it should be claimed now, or if we have hit
e71b65
the timeout and it should be released, since we didn't get any
e71b65
information from multipath. The safest thing to do is assume that this
e71b65
was the timeout, and the device shouldn't be claimed. The only time when
e71b65
this could be the wrong answer is when we first see a new multipath
e71b65
device, and it could only cause problems if there is metadata on the
e71b65
device that will cause it to get autoassembled by something else, before
e71b65
multipathd can autoassemble it. If we assume that it is a multipath
e71b65
device, or we assume that this wasn't actually the timeout uevent, we
e71b65
can keep a necessary device from getting released to the reset of the
e71b65
system.
e71b65
e71b65
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
e71b65
---
e71b65
 multipath/multipath.rules.in | 22 ++++++++++++++++------
e71b65
 1 file changed, 16 insertions(+), 6 deletions(-)
e71b65
e71b65
diff --git a/multipath/multipath.rules.in b/multipath/multipath.rules.in
e71b65
index 5c4447a2..70b69a06 100644
e71b65
--- a/multipath/multipath.rules.in
e71b65
+++ b/multipath/multipath.rules.in
e71b65
@@ -32,7 +32,8 @@ IMPORT{db}="DM_MULTIPATH_DEVICE_PATH"
e71b65
 
e71b65
 # multipath -u sets DM_MULTIPATH_DEVICE_PATH and,
e71b65
 # if "find_multipaths smart", also FIND_MULTIPATHS_WAIT_UNTIL.
e71b65
-IMPORT{program}="$env{MPATH_SBIN_PATH}/multipath -u %k"
e71b65
+IMPORT{program}=="$env{MPATH_SBIN_PATH}/multipath -u %k", \
e71b65
+	ENV{.MPATH_CHECK_PASSED}="1"
e71b65
 
e71b65
 # case 1: this is definitely multipath
e71b65
 ENV{DM_MULTIPATH_DEVICE_PATH}=="1", \
e71b65
@@ -83,10 +84,19 @@ LABEL="stop_wait"
e71b65
 # If timeout hasn't expired but we're not in "maybe" state any more, stop timer
e71b65
 # Do this only once, and only if the timer has been started before
e71b65
 IMPORT{db}="FIND_MULTIPATHS_WAIT_CANCELLED"
e71b65
-ENV{FIND_MULTIPATHS_WAIT_CANCELLED}!="?*", \
e71b65
-	ENV{FIND_MULTIPATHS_WAIT_UNTIL}=="?*", \
e71b65
-	ENV{FIND_MULTIPATHS_WAIT_UNTIL}!="0", \
e71b65
-	ENV{FIND_MULTIPATHS_WAIT_CANCELLED}="1", \
e71b65
-	RUN+="/usr/bin/systemctl stop cancel-multipath-wait-$kernel.timer"
e71b65
+ENV{FIND_MULTIPATHS_WAIT_CANCELLED}=="?*", GOTO="end_mpath"
e71b65
+ENV{FIND_MULTIPATHS_WAIT_UNTIL}!="?*", GOTO="end_mpath"
e71b65
+ENV{FIND_MULTIPATHS_WAIT_UNTIL}=="0", GOTO="end_mpath"
e71b65
+
e71b65
+ENV{FIND_MULTIPATHS_WAIT_CANCELLED}="1"
e71b65
+RUN+="/usr/bin/systemctl stop cancel-multipath-wait-$kernel.timer"
e71b65
+
e71b65
+# If "multipath -u" failed, no values are imported from the program,
e71b65
+# and we are still using the values for DM_MULTIPATH_DEVICE_PATH and
e71b65
+# FIND_MULTIPATHS_WAIT_UNTIL that were imported from the database.
e71b65
+# If we are in "smart" mode, we need to give up on the path now,
e71b65
+# since this may have been the timeout event. Without the imports
e71b65
+# from "multipath -u", we can't tell.
e71b65
+ENV{.MPATH_CHECK_PASSED}!="?*", ENV{DM_MULTIPATH_DEVICE_PATH}="0"
e71b65
 
e71b65
 LABEL="end_mpath"