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

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