From: Martin Wilck <mwilck@xxxxxxxx>
For existing paths, we don't need to force setting DI_WWID. It's
pointless because it would matter only in multipathd, and all
callers of update_multipath_table() / update_pathvec_from_dm()
in multipathd call it with flags=0, so this code won't be executed.
And this makes sense, because the path would either have been
cleanly initialized via path_discover() or an uevent, or pathinfo()
would have been called in update_pathvec_from_dm() in an earlier
invocation.
Also remove the misleading comment, and make coverity happy by
checking the return value of pathinfo().
---
Note: I haven't fully made up my mind whether we should act
on a pathinfo() failure here. For now, let the log message suffice.
Because the pathinfo flags are usually clear and pp->udev exists,
the only possible failure would be filtering by foreign libraries
or by devnode, which seems highly unlikely if it hasn't happened
beforehand.
Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Signed-off-by: Martin Wilck <mwilck@xxxxxxxx>
---
libmultipath/structs_vec.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libmultipath/structs_vec.c b/libmultipath/structs_vec.c
index df5709a..bfec840 100644
--- a/libmultipath/structs_vec.c
+++ b/libmultipath/structs_vec.c
@@ -149,16 +149,15 @@ bool update_pathvec_from_dm(vector pathvec, struct multipath *mpp,
* uninitialized struct path to pgp->paths, with only
* pp->dev_t filled in. Thus if pp->udev is set here,
* we know that the path is in pathvec already.
- * However, it's possible that the path in pathvec is
- * different from the one the kernel still had in its
- * map.
*/
if (pp->udev) {
if (pathinfo_flags & ~DI_NOIO) {
conf = get_multipath_config();
pthread_cleanup_push(put_multipath_config,
conf);
- pathinfo(pp, conf, pathinfo_flags|DI_WWID);
+ if (pathinfo(pp, conf, pathinfo_flags) != PATHINFO_OK)
+ condlog(2, "%s: pathinfo failed for existing path %s (flags=0x%x)",
+ __func__, pp->dev, pathinfo_flags);
pthread_cleanup_pop(1);
}
} else {
--
2.33.1
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
