On Sat, 2024-07-13 at 02:05 -0400, Benjamin Marzinski wrote: > If multipathd noticed that the WWID didn't match the device when > adding > a partial path, but removing it failed, multipathd wasn't disabling > the > path. Instead of calling handle_path_wwid_change(), which doesn't > make > much sense when multipathd is expecting a uevent, just manually > disable > the path if ev_remove_path() fails. > > Signed-off-by: Benjamin Marzinski <[email protected]> > --- > multipathd/cli_handlers.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/multipathd/cli_handlers.c b/multipathd/cli_handlers.c > index 0643be15..5d8ba3a6 100644 > --- a/multipathd/cli_handlers.c > +++ b/multipathd/cli_handlers.c > @@ -540,7 +540,11 @@ add_partial_path(struct path *pp, struct vectors > *vecs) > if (strlen(wwid) && strncmp(wwid, pp->wwid, WWID_SIZE) != 0) > { > condlog(0, "%s: path wwid changed from '%s' to '%s'. > removing", > pp->dev, wwid, pp->wwid); > - ev_remove_path(pp, vecs, 1); > + if (!(ev_remove_path(pp, vecs, 1) & > REMOVE_PATH_SUCCESS) && > + pp->mpp) { > + pp->dmstate = PSTATE_FAILED; > + dm_fail_path(pp->mpp->alias, pp->dev_t); > + } > udev_device_unref(udd); > return -1; > }
Is this sufficient? Can we be certain that this path won't be reinstated by sync_map_state() later on? That's at least not immediately obvious. Perhaps we should orphan the path? Martin
