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 <bmarzins@xxxxxxxxxx>
> ---
> 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
