OBS CI test aganst home:mwilck:multipath #4
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added in 5.11: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e4d2e82b2300b03f66b3ca8417590c86e661fab1 Cc: Mike Christie <michael.christie@oracle.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Benjamin Marzinski <bmarzins@redhat.com> Cc: Christophe Varoqui <christophe.varoqui@opensvc.com> Cc: DM-DEVEL ML <dm-devel@redhat.com> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Reviewed-by: Martin Wilck <mwilck@suse.com>
This patch implements support for the legacy SUSE feature "no_partitions" by mapping it to the more recent "skip_kpartx" feature in upstream multipath-tools.
SUSE udev rules rely on kpartx to create symlinks for dmraid devices Signed-off-by: Hannes Reinecke <hare@suse.de>
multipath -u needs ID_WWN für NVMe devices to determine the WWID. ID_WWN is currently set after multipath.rules is processed. Patches are under way to fix that (systemd/systemd#7594). Until then, insert a fallback rule here to make sure ID_WWN is set when multipath is called.
The upstream default for the path detection algorithm as changed with c36f2f4 "libmultipath: change find_multipaths option to multi-value". For backward compatibility with former SUSE releases, change the default to "greedy".
for compatibility with kpartx udev rules.
The message
3600a098000aad73f00000a3f5a275dc8: adding new path sdc
was meant to warn users in cases where multipathd hadn't obtained
information about a path device from udev, and found it later
in some multipath map. In regular operation, this may indicate
a problem with the udev db, stuck udev workers, or some race
between udev and multipathd. It could also be a normal situation,
e.g. after switching from the initrd to the root FS.
However, there's one mode of operation where this situation is normal:
the "check usable paths" mode (-C/-U). For performance reasons, multipath
doesn't do a full path discovery in this mode. It just reads the given
map. Thus encountering paths which aren't in pathvec is totally normal,
and will cause the above message for every path on every uevent for
a multipath device, which is highly confusing for users.
Reduce the log level of this message to 3. I think that's sufficient.
The reason I'd set it originall to level 2 was mainly that when I
worked on that code, I really didn't want to miss any of these messages.
Add compile and unittest workflow for Leap.
It turns out that Base:System doesn't work, as it has services disabled.
|
Braino it seems. |
mwilck
added a commit
that referenced
this pull request
Dec 1, 2021
... by the paths and pg vectors of the map to be removed.
Original bug report from Lixiaokeng ("libmultipath: clear removed path from mpp"):
multipathd[3525635]: ==3525635==ERROR: AddressSanitizer: heap-use-after-free on address 0xffffa4902fc0 at pc 0xffffac7d5b88 bp 0xffffa948dac0 sp 0xffffa948dae0
multipathd[3525635]: READ of size 8 at 0xffffa4902fc0 thread T7
multipathd[3525635]: #0 0xffffac7d5b87 in free_multipath (/usr/lib64/libmultipath.so.0+0x4bb87)
multipathd[3525635]: #1 0xaaaad6cf7057 (/usr/sbin/multipathd+0x17057)
multipathd[3525635]: #2 0xaaaad6cf78eb (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]: #3 0xaaaad6cff4df (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]: #4 0xaaaad6cfffe7 (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]: #5 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]: #6 0xaaaad6cf563f (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]: #7 0xffffac6877af (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]: #8 0xffffac44118b (/usr/lib64/libc.so.6+0xd518b)
multipathd[3525635]: 0xffffa4902fc0 is located 1344 bytes inside of 1440-byte region [0xffffa4902a80,0xffffa4903020)
multipathd[3525635]: freed by thread T7 here:
multipathd[3525635]: #0 0xffffac97d703 in free (/usr/lib64/libasan.so.4+0xd0703)
multipathd[3525635]: #1 0xffffac824827 in orphan_paths (/usr/lib64/libmultipath.so.0+0x9a827)
multipathd[3525635]: #2 0xffffac824a43 in remove_map (/usr/lib64/libmultipath.so.0+0x9aa43)
multipathd[3525635]: #3 0xaaaad6cf7057 (/usr/sbin/multipathd+0x17057)
multipathd[3525635]: #4 0xaaaad6cf78eb (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]: #5 0xaaaad6cff4df (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]: #6 0xaaaad6cfffe7 (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]: #7 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]: #8 0xaaaad6cf563f (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]: #9 0xffffac6877af (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]: #10 0xffffac44118b (/usr/lib64/libc.so.6+0xd518b)
When mpp only has one path and log out the path, there is an asan error.
In remove_mpp, the pp is freed firstly in orphan_path but is accessed,
changed in free_multipath later. Before free_path(pp), the pp should be
cleared from pp->mpp.
Reported-by: Lixiaokeng <lixiaokeng@huawei.com>
Tested-by: Lixiaokeng <lixiaokeng@huawei.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
mwilck
added a commit
that referenced
this pull request
Dec 2, 2021
... by the paths and pg vectors of the map to be removed.
Original bug report from Lixiaokeng ("libmultipath: clear removed path from mpp"):
multipathd[3525635]: ==3525635==ERROR: AddressSanitizer: heap-use-after-free on address 0xffffa4902fc0 at pc 0xffffac7d5b88 bp 0xffffa948dac0 sp 0xffffa948dae0
multipathd[3525635]: READ of size 8 at 0xffffa4902fc0 thread T7
multipathd[3525635]: #0 0xffffac7d5b87 in free_multipath (/usr/lib64/libmultipath.so.0+0x4bb87)
multipathd[3525635]: #1 0xaaaad6cf7057 (/usr/sbin/multipathd+0x17057)
multipathd[3525635]: #2 0xaaaad6cf78eb (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]: #3 0xaaaad6cff4df (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]: #4 0xaaaad6cfffe7 (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]: #5 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]: #6 0xaaaad6cf563f (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]: #7 0xffffac6877af (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]: #8 0xffffac44118b (/usr/lib64/libc.so.6+0xd518b)
multipathd[3525635]: 0xffffa4902fc0 is located 1344 bytes inside of 1440-byte region [0xffffa4902a80,0xffffa4903020)
multipathd[3525635]: freed by thread T7 here:
multipathd[3525635]: #0 0xffffac97d703 in free (/usr/lib64/libasan.so.4+0xd0703)
multipathd[3525635]: #1 0xffffac824827 in orphan_paths (/usr/lib64/libmultipath.so.0+0x9a827)
multipathd[3525635]: #2 0xffffac824a43 in remove_map (/usr/lib64/libmultipath.so.0+0x9aa43)
multipathd[3525635]: #3 0xaaaad6cf7057 (/usr/sbin/multipathd+0x17057)
multipathd[3525635]: #4 0xaaaad6cf78eb (/usr/sbin/multipathd+0x178eb)
multipathd[3525635]: #5 0xaaaad6cff4df (/usr/sbin/multipathd+0x1f4df)
multipathd[3525635]: #6 0xaaaad6cfffe7 (/usr/sbin/multipathd+0x1ffe7)
multipathd[3525635]: #7 0xffffac807be3 in uevent_dispatch (/usr/lib64/libmultipath.so.0+0x7dbe3)
multipathd[3525635]: #8 0xaaaad6cf563f (/usr/sbin/multipathd+0x1563f)
multipathd[3525635]: #9 0xffffac6877af (/usr/lib64/libpthread.so.0+0x87af)
multipathd[3525635]: #10 0xffffac44118b (/usr/lib64/libc.so.6+0xd518b)
When mpp only has one path and log out the path, there is an asan error.
In remove_mpp, the pp is freed firstly in orphan_path but is accessed,
changed in free_multipath later. Before free_path(pp), the pp should be
cleared from pp->mpp.
Reported-by: Lixiaokeng <lixiaokeng@huawei.com>
Tested-by: Lixiaokeng <lixiaokeng@huawei.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.