Blame SOURCES/0089-multipathd-trigger-udev-change-on-path-addition.patch

adddbf
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
adddbf
From: Benjamin Marzinski <bmarzins@redhat.com>
adddbf
Date: Mon, 17 Jan 2022 16:46:18 -0600
adddbf
Subject: [PATCH] multipathd: trigger udev change on path addition
adddbf
adddbf
When a multipath device is created for the first time, there is a window
adddbf
where some path devices way be added to the multipath device, but never
adddbf
claimed in udev. This can allow other device owners, like lvm, to think
adddbf
they can use the device.
adddbf
adddbf
When a multipath device is first created, all the existing paths that
adddbf
are not claimed by multipath have a uevent triggered so that they can
adddbf
get claimed. After that, multipath assumes all future paths added to the
adddbf
multipath device will have been claimed by multipath, since the device's
adddbf
WWID is now in the wwids file.  This doesn't work for any paths that
adddbf
have already been processed by the multipath.rules udev rules before
adddbf
the multipath device was created.
adddbf
adddbf
To close this window, when path device is added, and a matching
adddbf
multipath device already exists, multipathd now checks if the device is
adddbf
claimed by multipath, and if not, triggers a uevent to claim it.
adddbf
adddbf
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
adddbf
---
adddbf
 multipathd/main.c | 2 ++
adddbf
 1 file changed, 2 insertions(+)
adddbf
adddbf
diff --git a/multipathd/main.c b/multipathd/main.c
adddbf
index e2b9d546..f4b79882 100644
adddbf
--- a/multipathd/main.c
adddbf
+++ b/multipathd/main.c
adddbf
@@ -1005,6 +1005,8 @@ ev_add_path (struct path * pp, struct vectors * vecs, int need_do_map)
adddbf
 		free_path(pp);
adddbf
 		return 1;
adddbf
 	}
adddbf
+	if (mpp)
adddbf
+		trigger_path_udev_change(pp, true);
adddbf
 	if (mpp && mpp->wait_for_udev &&
adddbf
 	    (pathcount(mpp, PATH_UP) > 0 ||
adddbf
 	     (pathcount(mpp, PATH_GHOST) > 0 &&