Blame SOURCES/0064-multipathd-Handle-losing-all-path-in-update_map.patch

86e138
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
86e138
From: Benjamin Marzinski <bmarzins@redhat.com>
86e138
Date: Tue, 9 Aug 2022 16:46:28 -0500
86e138
Subject: [PATCH] multipathd: Handle losing all path in update_map
86e138
86e138
Its possible that when a multipath device is being updated, it will end
86e138
up that all the paths for it are gone. This can happen if paths are
86e138
added and then removed again before multipathd processes the uevent for
86e138
the newly created multipath device. In this case multipathd wasn't
86e138
taking the proper action for the case where all the paths had been
86e138
removed. If flush_on_last_del was set, multipathd wasn't disabling
86e138
flushing and if deferred_remove was set, it wasn't doing a deferred
86e138
remove. Multipathd should call flush_map_nopaths(), just like
86e138
ev_remove_path() does when the last path is removed.
86e138
86e138
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
86e138
Reviewed-by: Martin Wilck <mwilck@suse.com>
86e138
---
86e138
 multipathd/main.c | 4 ++++
86e138
 1 file changed, 4 insertions(+)
86e138
86e138
diff --git a/multipathd/main.c b/multipathd/main.c
86e138
index 68ee067b..d2c48d3b 100644
86e138
--- a/multipathd/main.c
86e138
+++ b/multipathd/main.c
86e138
@@ -529,6 +529,10 @@ retry:
86e138
 		goto fail;
86e138
 	}
86e138
 	verify_paths(mpp);
86e138
+	if (VECTOR_SIZE(mpp->paths) == 0 &&
86e138
+	    flush_map_nopaths(mpp, vecs))
86e138
+		return 1;
86e138
+
86e138
 	mpp->action = ACT_RELOAD;
86e138
 
86e138
 	if (mpp->prflag) {