libmutipath: continue to use old state on PATH_PENDING
authorBenjamin Marzinski <bmarzins@redhat.com>
Sat, 30 Mar 2019 06:05:57 +0000 (01:05 -0500)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Thu, 18 Apr 2019 11:03:36 +0000 (13:03 +0200)
commite224d57a13cb08d0914ea950e0095a0cd10638b6
tree1ec7670fca6e1f0d3fe817c57ff409bda7497f7f
parent3ad48a0bc002f3d1b2a27eafecfd7fbb390bfb94
libmutipath: continue to use old state on PATH_PENDING

When pathinfo() sets pp->state to PATH_PENDING, it can cause problems
with path checking.  It should act more like check_path(). When
check_path() sees a new state of PATH_PENDING, it doesn't update the
path state at all, so a path's old state is normally never PATH_PENDING.

As and example of the problems of setting a path to PATH_PENDING, If
check_path() sets a path's state to PATH_UP, then a call to pathinfo()
sets the state to PATH_PENDING, and then another call the check_path()
sets the state to PATH_DOWN, multipathd won't fail the path in the
kernel. Also, if a path's state is PATH_PENDING, and nr_active is
recalculated, that path will count as down, even if the state was
previously PATH_UP. If a path already has a state of PATH_WILD or
PATH_UNCHECKED, changing it to PATH_PENDING won't hurt anything, and it
will help anyone who sees it know what's actually happening. But
otherwise, pathinfo() should leave the previous state alone.

Reviewed-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
libmultipath/discovery.c