If a reconfigure is delayed because multipathd is waiting on a change
uevent for a new multipath device, the main thread will not pause, but
will keep looping and rechecking to see if it can reconfigure.
To solve this, when __post_config_state(DAEMON_IDLE) is called, if
__delayed_reconfig is set we really do want to switch to the
DAEMON_IDLE state, even if there is a pending reconfigure, since it's
being delayed. When the last change uevent for a new map arrives (or
we time out waiting for it), a reconfigure will get triggered.
However, we need to avoid a race where the main thread calls
enable_delayed_reconfig() and sets __delayed_reconfig, and then the
uevent thread processes a change uevent that sets the state to
DAEMON_CONFIGURE, an then the main thread calls post_config_state().
In this case, multipathd would move to DAEMON_IDLE, even though
the reconfigure should no longer be delayed. To avoid this, when
schedule_reconfigure() is called and the daemon is currently in
DAEMON_CONFIGURE or DAEMON_RUNNING, __delayed_reconfig should be
cleared, so switching to DAEMON_IDLE will instead become
DAEMON_CONFIGURE.
Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
---
multipathd/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/multipathd/main.c b/multipathd/main.c
index 86b1745a..9bd1f530 100644
--- a/multipathd/main.c
+++ b/multipathd/main.c
@@ -309,6 +309,7 @@ static void __post_config_state(enum daemon_status state)
* again and start another reconfigure cycle.
*/
if (reconfigure_pending != FORCE_RELOAD_NONE &&
+ !__delayed_reconfig &&
state == DAEMON_IDLE &&
(old_state == DAEMON_CONFIGURE ||
old_state == DAEMON_RUNNING)) {
@@ -353,6 +354,7 @@ void schedule_reconfigure(enum force_reload_types requested_type)
break;
case DAEMON_CONFIGURE:
case DAEMON_RUNNING:
+ __delayed_reconfig = false;
reconfigure_pending = type;
break;
default:
--
2.17.2
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
