Bug ID 1139369
Summary multipath-tools: post-0.8.1 upstream bug fixes
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component Basesystem
Assignee bnc-team-screening@forge.provo.novell.com
Reporter martin.wilck@suse.com
QA Contact qa-bugs@suse.de
Found By ---
Blocker ---

Upstream multipath-tools fixes from dm-devel, post 0.8.1

1) libmultipath: make vector_foreach_slot_backwards work as expected
- Matters only for foreign/NVMe code (also for "multipath -W", but without user
noticeable impact)
  => Factory/SLE15-SP1 only

QA test case: Use NVMe native multipath and run multipathd. Remove one or more
NVMe paths. => multipathd crashes.

2) multipathd: fix REALLOC_REPLY with max length reply
- fix for cd5a9797e "libmpathcmd(coverity): limit reply length"
- Factory/SLE15-SP1 only, the others don't contain the broken commit

QA test case: None, corner case which occurs only if a client command gets a
reply with >= 32768 bytes.

3) multipath: call store_pathinfo with DI_BLACKLIST 
- performance; cli_add_path() may add blacklisted path
- Factory, SLE15, SLE15-SP1, SLE12-SP3/4 

QA test case: Blacklist some paths (by any mechanism other than devnode).
Verify that "multipathd show paths" doesn't list the blacklisted devices
Run "multipathd add path $X" where $X is one of the blacklisted paths.
 => ok (expected: fail with msg "blacklisted").

4) multipathd: fix client response for socket activation
- minor corner-case fix 
- Factory/SLE15-SP1 only

QA test case: stop multipathd on a system with some multipath maps. Run
"multipathd show topology"  
=> success with empty output (expected: success with correct topology output)

5) libmultipath: get_prio(): really don't reset prio for inaccessible paths
- Factory, SLE15, SLE12-SP4, SLE15-SP1

QA test case: perhaps reproducible with a setup with lots of pass
loss/reinstate events, by monitoring the topology with "group_by_prio". It's a
rare condition though which happens only if a path becomes inaccessible in the
small time windw between the state check and the get_prio() call in pathinfo().
See bug 1118495.


You are receiving this mail because: