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

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