On Thu, Jul 09, 2020 at 12:36:15PM +0200, mwi...@suse.com wrote:
> From: Martin Wilck <mwi...@suse.com>
>
> Since 65e1845 ("multipath: call store_pathinfo with DI_BLACKLIST"), we
> use DI_BLACKLIST for new paths. There's no reason why we shouldn't do the
> same with paths which are (unexpectedly) already in pathvec. As argued
> for 65e1845, this might save some unnecessary work for paths which are
> blacklisted anyway.
It seems to me like either we should assume that if we added the path to
pathvec, it's valid, or we should check, and if it's blacklisted, remove
it. Just leaving it on pathvec without all of the pathinfo work done
doesn't make much sense to me. Am I missing something here?
-Ben
> Signed-off-by: Martin Wilck <mwi...@suse.com>
> ---
> libmultipath/discovery.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
> index 5f4ebf0..caabfef 100644
> --- a/libmultipath/discovery.c
> +++ b/libmultipath/discovery.c
> @@ -137,7 +137,7 @@ path_discover (vector pathvec, struct config * conf,
> udevice, flag | DI_BLACKLIST,
> NULL);
> else
> - return pathinfo(pp, conf, flag);
> + return pathinfo(pp, conf, flag | DI_BLACKLIST);
> }
>
> static void cleanup_udev_enumerate_ptr(void *arg)
> --
> 2.26.2
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
