All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/9] multipath-tools: more small fixes
@ 2026-01-09 18:38 Martin Wilck
  2026-01-09 18:38 ` [PATCH 1/9] libmultipath: reset pgindex in uninitialize_path() Martin Wilck
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: Martin Wilck @ 2026-01-09 18:38 UTC (permalink / raw)
  To: Benjamin Marzinski, dm-devel; +Cc: Christophe Varoqui

1 and 2 are minor cleanups. 

Patch 3-5 are follow-ups of the structure-freeing cleanup of my
previous patch series "Multipath-tools: various bug fixes".
The previous series tried to make sure that no freed "struct multipath"
objects are ever referenced by any "struct path" objects. To achieve
that, it nullified pp->mpp links from all paths in a struct multipath
when the latter was discarded in free_multipath(). This is only safe
if we make sure that the path referenced by a struct multipath (either
via mpp->paths or mpp->pg[i]->paths for some i), aren't freed before
the struct multipath itself. Ideally, the orphaning in free_multipath()
wouldn't need to happen if we'd make sure that pp->mpp is set *if and
only if* pp was referenced by mpp as explained above. I think we do
a decent job at that, but it's hard to tell with 100% confidence.

In order to improve confidence, patch 4 and 5 add some logging. It's now an
error if a path which is freed still links to a multipath map. Patch 3/5
eliminates a few cases where this could still happen, even though the path was
not member of the map. Patch 5 is mainly meant to debug cases pp->mpp was
either NULL or pointing to a different map. This shouldn't happen and I
haven't observed it in my testing so far.

Patch 6 avoids a strange behavior that multipathd has had forever - after
grouping paths, mpp->paths was freed. In most of our code, we assume that
mpp->paths and mpp->pg should reference the same set of path devices, and
we have update_mpp_paths() and sync_paths() to take care of it. But right
after path grouping, this is not the case. Subsequent invocations of
update_mpp_path() (usually via refresh_multipath()) will re-allocate and
fill the paths vector. This causes a lot of unnecessary heap operations.

Patch 7 and 8 are unrelated bug fixes which I came across lately.

Patch 9 is motivated by the recent patch "libmpathutil: use union for bitfield".
I did some further experiments with strict aliasing and found that the
multipath-tools code base just should not use it at all. Like the kernel,
we use between low-level data structures that don't comply with strict
aliasing rules. So like the kernel, we should disable strict aliasing.
That basically obsoletes "libmpathutil: use union for bitfield", but having
it doesn't hurt, either.

Interestingly, switching to -fno-strict-aliasing seems to have fixed [1],
which I'd unsuccessfully tried to fix with various methods before.

[1] https://github.com/opensvc/multipath-tools/issues/130

Martin Wilck (9):
  libmultipath: reset pgindex in uninitialize_path()
  libmultipath: clarify code in set_path_removed()
  libmultipath: nullify pp->mpp before calling free_path()
  libmultipath: log error when freeing path that refers to a map
  libmultipath: sync_paths(): print message when fixing pp->mpp
  libmultipath: don't free mpp->paths in group_paths()
  libmultipath: warn only once in scsi_tmo_error_msg()
  libmultipath: find_hwe(): fix gcc errors at high optimization levels
  multipath-tools: compile with -fno-strict-aliasing

 Makefile.inc               |  2 +-
 libmultipath/config.c      | 13 ++++++++++---
 libmultipath/discovery.c   |  3 +++
 libmultipath/pgpolicies.c  |  2 --
 libmultipath/structs.c     |  4 ++++
 libmultipath/structs_vec.c | 26 +++++++++++++++++---------
 tests/pgpolicy.c           |  7 +++++--
 7 files changed, 40 insertions(+), 17 deletions(-)

-- 
2.52.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-01-13 20:56 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-09 18:38 [PATCH 0/9] multipath-tools: more small fixes Martin Wilck
2026-01-09 18:38 ` [PATCH 1/9] libmultipath: reset pgindex in uninitialize_path() Martin Wilck
2026-01-09 18:39 ` [PATCH 2/9] libmultipath: clarify code in set_path_removed() Martin Wilck
2026-01-09 18:39 ` [PATCH 3/9] libmultipath: nullify pp->mpp before calling free_path() Martin Wilck
2026-01-09 18:39 ` [PATCH 4/9] libmultipath: log error when freeing path that refers to a map Martin Wilck
2026-01-09 18:39 ` [PATCH 5/9] libmultipath: sync_paths(): print message when fixing pp->mpp Martin Wilck
2026-01-09 18:39 ` [PATCH 6/9] libmultipath: don't free mpp->paths in group_paths() Martin Wilck
2026-01-09 18:39 ` [PATCH 7/9] libmultipath: warn only once in scsi_tmo_error_msg() Martin Wilck
2026-01-09 18:39 ` [PATCH 8/9] libmultipath: find_hwe(): fix gcc errors at high optimization levels Martin Wilck
2026-01-09 18:39 ` [PATCH 9/9] multipath-tools: compile with -fno-strict-aliasing Martin Wilck
2026-01-13 20:56 ` [PATCH 0/9] multipath-tools: more small fixes Benjamin Marzinski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.