[dm-devel] [PATCH 1/5] multipathd: don't fail to remove path once the map is removed

[Benjamin Marzinski]

On Wed, May 12, 2021 at 09:11:01AM +0000, Martin Wilck wrote:
> On Tue, 2021-05-11 at 18:22 -0500, Benjamin Marzinski wrote:
> > In ev_remove_path(), if update_mpp_paths() fails, we delete the
> > entire
> > map. However, since update_mpp_paths() happens before we call
> > set_path_removed(), pp->initialized isn't set to INIT_REMOVED, so
> > remove_map_and_stop_waiter() doesn't remove the path when in removes
> > the
> > map.  But with the map removed, there's nothing to keep us from
> > removing
> > the path.
> > 
> > Call set_path_removed() before update_mpp_paths() to avoid the odd
> > case
> > of ev_remove_path() removing the map but not the path.
> > 
> > Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>
> > ---
> >  libmultipath/structs_vec.c |  3 +--
> >  multipathd/main.c          | 13 ++++++++-----
> >  2 files changed, 9 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libmultipath/structs_vec.c b/libmultipath/structs_vec.c
> > index d242c06b..432c0c63 100644
> > --- a/libmultipath/structs_vec.c
> > +++ b/libmultipath/structs_vec.c
> > @@ -45,8 +45,7 @@ int update_mpp_paths(struct multipath *mpp, vector
> > pathvec)
> >  
> >                                 /*
> >                                  * Avoid adding removed paths to the
> > map again
> > -                                * when we reload it. Such paths may
> > exist if
> > -                                * domap fails in ev_remove_path().
> > +                                * when we reload it.
> 
> I'd like to keep the remark about domap(). It's meant as a reminder for
> us and future developers how this situation is most likely to come to
> pass.

Sure. I just removed it, since we now call update_mpp_paths immediately
after calling set_path_removed(), so it seemed more obvious that we will
run into this situation than it did before, when it only happened if we
first failed in ev_remove_path(). I'm fine with putting it back.

> 
> Other than that, ACK.
> 
> Regards,
> Martin