multipath-tools 0.9.5

GitHub has ended Ubuntu 18.04 (bionic) support in 12/22.
Remove the 18.04 runner, and use Ubuntu 22.04 (jammy) instead. While at it,
use a matrix for the build. This way we get gcc-9 and clang-10 on
20.04, and gcc-11 and clang-14 on 22.04.

Jammy-related cludges for the workflow:

 - We need to install linux-modules-extra to be able to use the zram device.
 - valgrind doesn't support the dwarf-5 format that clang-14 generate
   by default. See e.g. https://bugs.kde.org/show_bug.cgi?id=452758

LIO always responds with GOOD status to TUR. Thus TUR is
not useful as path checker for LIO targets.

Fixes #54

mwilck: v2: fixed up with .detect_checker setting.

Reported-by: Li Xiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Tested-by: Li Xiaokeng <lixiaokeng@huawei.com>

This "Also=" directive is wrong. It was meant for enabling socket activation,
but it actually does the opposite. "Also=multipathd.socket" means that
enabling/disabling the service will enable/disable the socket, too. This is
not what we want: socket activation means that we can enable the socket
while the service is disabled and will be activated by the socket on demand.

See dracutdevs/dracut#2290,
#65

Fixes: ca985df ("multipathd: switch to socket activation for systemd")
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

Unsupported designators, even if they are correct, will result
in parsing errors. Add support for these two:

Logical Unit Group (0x6)
Vendor Specific (0x0)

Mar 20 13:37:35 init107-18 multipath[45016]: parse_vpd_pg83:
invalid device designator at offset 87: 01060004
Mar 20 13:37:35 init107-18 multipath[45016]: parse_vpd_pg83:
invalid device designator at offset 131: 02000005

Thanks,
Brian

mwilck: added descriptor type 7 (MD5) for completeness.

Signed-off-by: Brian Bunker <brian@purestorage.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

Otherwise, when CFLAGS/CPPFLAGS have multiple entries (like "-O2 -pipe"), we
get an error:
```
make[1]: Entering directory '/var/tmp/portage/sys-fs/multipath-tools-0.9.4/work/multipath-tools-0.9.4/tests'
/bin/sh: line 1: -pipe: command not found
make[1]: *** [Makefile:115: libmultipath.so.0] Error 127
make[1]: *** Waiting for unfinished jobs....
```

Signed-off-by: Sam James <sam@gentoo.org>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Some generated .d files were not correctly included, and not
removed with "make dep_clean". Fix it.

Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Tested-by: Xose Vazquez Perez <xose.vazquez@gmail.com>

694a29d ("libmultipath: limit paths that can get wwid from environment")
added the pp->can_use_env_uid, which is used in get_uid() and it's caller,
pathinfo().

Signed-off-by: Martin Wilck <mwilck@suse.com>

Currently, whenever getting the uid_attribute from the udev database
fails, multipath will try to get it from the environment variables. This
normally isn't a problem, since either multipath -u is getting called
from a uevent and the environment will have the correct value in that
variable, or something else is being run and that variable won't be set.
However, when find_multipaths is configured to "smart", this causes
problems. For maybe devices, multipath needs to get the WWIDs of all the
other block devices, to see if they match the maybe device wwid.  If one
of those devices doesn't have uid_attribute set in its udev database,
multipath will fall back to checking the environment for it, and it will
find that variable set to the WWID of the maybe device that this uevent
is for.  This means that all devices with no WWID will end up appearing
to have the same WWID as the maybe device, causing multipath to
incorrectly claim it.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Otherwise the build fails with userspace-rcu 0.14 with

   error: implicit declaration of function 'assert' [-Werror=implicit-function-declaration]
   note: 'assert' is defined in header '<assert.h>'; did you forget to '#include <assert.h>'?

Until liburcu 0.13.0, this didn't show up as a compile error, because
"assert.h" was pulled in via config.h -> urcu.h.

But these assert() calls should have been cmocka assert macros
in the first place.

Signed-off-by: Dirk Müller <dirk@dmllr.de>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

If a the tur checker creates a new context because an old thread is
still running, but the old thread finishes before the checker drops
the old context, the checker should reset nr_timeouts to 0, since
the old thread did complete in time.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>
Tested-by: Brian Bunker <brian@purestorage.com>

The tur checker has a message for initialization failure. We might as
well use it.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>
Tested-by: Brian Bunker <brian@purestorage.com>

The tur checker should not return that a path is down when it is in the
transitioning state. Instead, it should return PATH_PENDING, so that
the path retains its current state, and multipathd can react quickly
when it moves out of the transitioning state.

The code needs to be careful to differentiate between when the checker
thread has finished and returned PATH_PENDING, and when it is still
running.

Reported-by: Brian Bunker <brian@purestorage.com>
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>
Tested-by: Brian Bunker <brian@purestorage.com>

If "multipath -u" fails, udev doesn't import any values from the
program. This means that multipath.rules will continue to use the values
for DM_MULTIPATH_DEVICE_PATH and FIND_MULTIPATHS_WAIT_UNTIL that it has
already imported from the database. This is the correct thing to do for
every case except the MAYBE case for "find_multipaths smart". In that
case, DM_MULTIPATH_DEVICE_PATH will be set to 1, and the rules will
assume that the device has been definitively claimed.

In this case, we know that the device shouldn't have been claimed
before, but we don't know if it should be claimed now, or if we have hit
the timeout and it should be released, since we didn't get any
information from multipath. The safest thing to do is assume that this
was the timeout, and the device shouldn't be claimed. The only time when
this could be the wrong answer is when we first see a new multipath
device, and it could only cause problems if there is metadata on the
device that will cause it to get autoassembled by something else, before
multipathd can autoassemble it. If we assume that it is a multipath
device, or we assume that this wasn't actually the timeout uevent, we
can keep a necessary device from getting released to the reset of the
system.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

The "no available paths" case would leak the memory resp points to.
Found by coverity.

Fixes: 50e2c16 ("multipathd: handle no active paths in update_map_pr")

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

If select_action() is called and a multipath device needs to be renamed,
the code currently checks if force_reload is set, and if so, does the
reload after the rename.  But if force_reload isn't set, only the rename
happens, regardless of what other actions are needed. This can happen if
multipathd starts up and a device needs both a reload and a rename.

Make multipath check for resize, reload, and switch pathgroup along with
rename, and do both if necessary.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Combine the two separate blocks that set ACT_CREATE into one.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

The ACT_RESIZE action is the same as the ACT_RELOAD action, except that
it flushes outstanding IO because the device size is changing and
the new size might be too small for some of the outstanding IO. If we've
detected a size change, and a forced reload is requested, we still need
to flush the IO because the reload will change the device size.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Since we have a function to set the action to reload, use it.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Commit 6b81153 ("libmultipath: make prflag an enum") changed
the size and member offsets of struct multipath.

…ties

Some SAS devices (e.g. Seagate factory recertified 'white label' drives) may
come with the Vendor field blank. This causes Multipath to fail to
complete the discovery of those devices.

Such devices violate the SCSI Spec. From the SPC-6, §6.7.2:
"The T10 VENDOR IDENTIFICATION field contains eight bytes of left-aligned
ASCII data (see 4.3.1) identifying the manufacturer of the logical unit. The
T10 vendor identification shall be one assigned by INCITS.".

But as we don't identify WWIDs by vendor and product, we don't need to discard
these devices right away. We can go ahead fingers crossed, and hope that the
the other VPD pages for the device are correct.

We obviously can't look up reasonable device properties for such devices in
our hwtable. It would be up to the user to deal with that.

Reported by: Allyn Malventano (github.com//issues/56)
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

On systems with many LUNs, multipathd may fail to respond within the
default timeout to a "setprkey" command because the vecs lock is held
by the path checker. Honor the globally configured uxsock timeout in
libmpathpersist.

Reported-by: boposki (github.com//pull/58)
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

To check whether we will be able to add a given device can be part
of a multipath map, we have two tests in check_path_valid():
released_to_systemd() and the O_EXCL test. The former isn't helpful
if "multipath -u" is called for the first time for a given device,
and the latter is only used in the "find_multipaths smart" case, because
actively opening the device with O_EXCL, even for a very short time, is prone
to races with other processes.

It turns out that this may cause issues in some scenarios. We saw problems in
once case where "find_multipaths greedy" was used with a single
non-multipahted root disk and a very large number of multipath LUNs.
The root disk would first be classified as multipath device. multipathd
would try to create a map, fail (because the disk was mounted) and
trigger another uevent. But because of the very large number of multipath
devices, this event was queued up behind thousands of other events, and
the root device timed out eventually.

While a simple workaround for the given problem would be proper blacklisting
or using a different find_multipaths mode, I am proposing a different
solution here. An additional test is added in is_path_valid() which
checks whether the given device is currently in use by 1. sysfs holders,
2. mounts (from /proc/self/mountinfo) or 3. swaps (from /proc/swaps). 2.
and 3. are similar to systemd's device detection after switching root.
This must not only be done for the device itself, but also for all its
partitions. For mountinfo and swaps, libmount is utilized.

With this patch, "multipath -u" will make devices with mounted or otherwise
used partitions available to systemd early, without waiting for multipathd
to fail setting up the map and re-triggering an uevent. This should avoid
the issue described above even without blacklisting. The downside of it
is a longer runtime of "multipath -u" for almost all devices, in particular
for real multipath devices. The runtime required for the new checks was in the
order of 0.1ms-1ms in my tests. Moreover, there is a certain risk that devices may
wrongly classified as non-multipath because of transient mounts or holders
created by other processes.

To make this code compile on older distributions, we need some additional
checks in create-config.mk.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

If coalesce_paths() is called without a mpvec, it will free all the
multipath devices on newmp at the end. This will clear pp->mpp from the
path, but it doesn't completely unitialize them. cli_add_map() can call
coalsce_paths() this way, when adding a device that doesn't currently
exist. cli_add_map() first creates the device in the kernel, and then
calls ev_add_map() to add it to multipathd. If something goes wrong in
ev_add_map(), the paths will still be initialized, even though they're
orphans.

Fix this by calling remove_map() to orphan the paths that belong to
the multipath devices being deleted by coalesce_paths().

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Instead of repeatedly removing the first vector element, and shifting
the rest to fill in, call remove_map() without a vector, so it just
frees the devices. The vector will be completely cleaned up by
vector_free() immediately afterwards.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

When a multipath device is first created, if it has a reservation key
configured, update_map_pr() will check for a matching key on the active
paths. If there were no active paths to check with, multipathd was
leaving mpp->prflag in PRFLAG_UNSET, as if there were no matching keys.
It's possible that when update_map_pr() is called, all the paths will be
in the PATH_PENDING state because the checkers haven't completed yet. In
this case, multipathd was treating the device as having no registered
keys without ever checking.

To solve this, multipath devices now start with prflag = PRFLAG_UNKNOWN.
It will remain in this state until multipathd actually tries to get the
registered keys down a path. If the map is in this state, it will check
newly active paths, and if it finds a matching key, it will register
the key down all active paths.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

In preparation for a future patch, make prflag an enum, and change the
reply of cli_getprstatus() to a string.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

multipathd was inconsistent on what it did with persistent reservations
when a multipath device was created. If a multipath device with a
configured reservation key was created during configure(), multipathd
would try to read the registered keys using an active path. If it saw a
matching key, it would set the prflag, but not attempt to register the
key on any of the other paths.  This means that if a new path had
appeared while multipathd was not running, it wouldn't register the key
on this path.

If the multipath device was created during ev_add_path(), multipathd
would used the added path to check if there was a matching key and if
there was, register the key only on the added path and then set the
prflag. This could be problematic if the device was created with
multiple paths, for instance because find_mutipaths was set to "yes" and
a second path just appeared. In this case, if the device happened to be
only registered on the second path, it would not get registered on the
first path.

If the multipath device was added to multipathd during a call to
ev_add_map(), multipathd wouldn't set the prflag or register the key on
any paths.

After a device was created with the prflag set, if a new path appeared
before the creation uevent, and multipathd was forced to delay adding
it, when it finally updated the multipath device, the key would be
registered on all paths, fixing any paths missed during creation.
However, if a new path appeared after the creation uevent, the key would
only be registered on that new path. Any paths that were missed on
creation would stay missed.

persistent key registration needs to be handled consistently.  This
patch does so by making sure that however a multipath device is added to
multipathd, it will check to see if the configured key is registered. If
it is, multipathd will set the prflag and register the key on all the
currently active paths.

When a new path is added, multipathd will use it to check for active
keys, as before. But if it finds a matching key and prflag isn't
currently set, it will register the key on all paths.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

multipath-tools 0.9.4: Makefile overhaul, and some bug fixes

Signed-off-by: Martin Wilck <mwilck@suse.com>

The features, path_selector, and hardware_handler config options pass
their strings directly into the kernel.  If users omit the argument
counts from these strings, or use the wrong value, the kernel's table
parsing gets completely messed up, and the error messages it prints
don't reflect what actully went wrong. To avoid messing up the
kernel table parsing, verify that these strings correctly set the
argument count to the number of arguments they have.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

If set_path() or set_str_noslash() are called with a bad value, they
ignore it and continue to use the old value. But they weren't freeing
the bad value, causing a memory leak.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>

alloc_strvec() will never create a strvec with multiple tokens between
the quote tokens.  Verify this in validate_config_strvec(), and simplify
set_value() by only reading one value after a quote token.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>