Only for "abi" not yet, we need make sure that it's output remains
unchanged if we change the runner.

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

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

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

My previous patch "libmultipath: fix dev_loss_tmo even if not set in
configuration" implicitly assumed that DEV_LOSS_TMO is 0, which is true
but unclean. Make the intention of the code more explicit.

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

If the nvme native multipath driver is enabled, blacklist nvme devices
for dm-multipath by default. This is particularly useful with
"find_multipaths greedy".

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

If pp->dev_loss_tmo == DEV_LOSS_TMO_UNSET, sysfs_set_scsi_tmo() would
not set it to min_dev_loss_tmo, causing the system dev_loss_tmo value
(by default, 30s) to remain unchanged. Fix it.

Fixes: 6ad77db ("libmultipath: Set the scsi timeout parameters by path")
Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>

Issue found by coverity:
  CID 393674:  Code maintainability issues  (UNUSED_VALUE)
  Assigning value "NULL" to "mpp" here, but that stored value is overwritten
  before it can be used.

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

It would appear KBUILD_BUILD_TIMESTAMP is meant to be used the same way as in
the linux kernel build. For linux, builders are supposed to set
KBUILD_BUILD_TIMESTAMP in the environment if they want a stable timestamp.

The libddmmp makefile however tries to directly call git to get a timestamp,
which fails in a typical Debian build environment, which is not a full git
source tree.

Have libdmmp/Makefile use KBUILD_BUILD_TIMESTAMP from the environment if
available, otherwise use git as before.

mwilck: changed slightly, preserving the original logic

Signed-off-by: Chris Hofstaedtler <zeha@debian.org>
Signed-off-by: Martin Wilck <mwilck@suse.com>

Debian's build system helpers automatically set "PKG_CONFIG" correctly, so it
would be convenient for Debian to use this name instead of "PKGCONFIG".

The majority of projects also seem to call this makefile variable "PKG_CONFIG".

Signed-off-by: Chris Hofstaedtler <zeha@debian.org>
Acked-by: Sam James <sam@gentoo.org>
Reviewed-by: Martin Wilck <mwilck@suse.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>

When need_switch_pathgroup() is called by deferred_failback_tick(),
there is a chance that mpp->paths will be NULL, even if there are paths
in the multipath device's pathgroups. Instead check if there are
multiple pathgroups, since multipath can't be using the wrong pathgroup
if there is one or none.

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

need_switch_pathgroup() only checks if the currently used pathgroup is
not the highest priority pathgroup. If it isn't, all multipathd does is
instruct the kernel to switch to the correct pathgroup.  However, the
kernel treats the pathgroups as if they were ordered by priority. When
the kernel runs out of paths to use in the currently selected pathgroup,
it will start checking the pathgroups in order until it finds one with
usable paths.

need_switch_pathgroup() should also check if the pathgroups are out of
order, and if so, multipathd should reload the map to reorder them
correctly.

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

Multipathd previously had various rules to update priorities in
update_prio(), need_switch_pathgroup(), and reload_map(). Instead, only
update the priority in update_prio().  To cover the cases where the
priorities were getting updated in other functions, update_prio() now
always updates all paths' priorities, if the priority on the path that
it was called with changes.

Also, do not try to update a path's priority if it is down. Previously,
when refreshing all the paths' priorities, a path could have its
priority updated when it was in the PATH_DOWN state, as long as its
priority was PRIO_UNDEF. But if a path is down, and the last time
multipath tried to get its priority, it failed, it seems likely that the
prioritizer will just fail again.

Finally, skip updating all paths' priorities in
deferred_failback_tick().  Now that all the paths' priorities will get
updated when one changes before starting the deferred failback count,
it's no longer necessary to update them all again when the failback
timeout expires.  The checker loop will continue to update them
correctly while the timeout is going on.

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

Make sure that pathgroups that include paths with a PRIO_UNDEF priority
are properly sorted.

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

When multipath is not set to group_by_prio, different paths in a
pathgroup can have different priorities. If there is a problem getting
the priority of an active path, its priority will be set to PRIO_UNDEF.
This will change the priority of the whole pathgroup, even though it's
likely that this is simply a temporary error. Instead, do not count
PRIO_UNDEF paths towards to priority of the path group, unless there are
no paths that have an actual priority. This will not effect the priority
of multipath devices with group_by_prio, since all paths in a pathgroup
will have the same priority.

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

If this and "detect_pgpolicy" are both selected and ALUA is
autodetected, the multipath device will use the "group_by_tpg" policy
instead of the "group_by_prio" policy.

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

This allows configuations to use "group_by_prio" if alua is autodetected
and another policy if it isn't, so they can work with detect_prio.

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

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

Make it possible to easily check a path's target port group.

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

copying the value into a passed in buffer doesn't help any of the
callers of this function. It's just wasted work.

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

When we group paths by prio and the priority changes, paths can end up
temporarily in the wrong path groups.  This usually happens when some
paths are down, so their priority can't be updated. To avoid this for
ALUA paths, group them by their target port group instead. The path
groups chosen by this policy won't always match with those chosen by
group_by_prio, since it is possible for multiple ALUA target port
groups to have the same priority.

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

libmultipath/structs_vec.c:270: mulitpath ==> multipath
libmultipath/libmultipath.version:36: overriden ==> overridden
libmpathutil/libmpathutil.version:36: overriden ==> overridden

SUMMARY:
mulitpath     1
overriden     2

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>

…tibus

ALUA is needed by Hitachi Global-Active Device (GAD):
https://knowledge.hitachivantara.com/Documents/Management_Software/SVOS/8.1/Global-Active_Device/Overview_of_global-active_device

(Information about ALUA support from personal communication from Hitachi).

"no_path_retry" recommendation from:
https://knowledge.hitachivantara.com/Documents/Management_Software/SVOS/9.8.6/Volume_Management_-_VSP_5000_Series/Host_Attachment/05_Red_Hat_Linux_configuration_and_attachment#Device_Mapper_(DM)_Multipath_configuration.0D.0A____for_Red_Hat_Linux

Cc: Matthias Rudolph <Matthias.Rudolph@hitachivantara.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>

Fix the following warning reported by udevadm verify:

kpartx/dm-parts.rules:35 A comma between tokens is expected.
kpartx/dm-parts.rules: udev rules check failed

Note (mwilck): technically, this udev rule was parsed and
executed by udev correctly, and this is unlikely to change.
But the missing comma didn't comply with the udev(7) man page.
This commit fixes that.

Signed-off-by: Dmitry V. Levin <ldv@strace.io>
Reviewed-by: Martin Wilck <mwilck@suse.com>

Fix warnings reported by udevadm verify:

multipath/11-dm-mpath.rules:18 Whitespace after comma is expected.
...
multipath/11-dm-mpath.rules: udev rules check failed

Note (mwilck): technically, the syntax of the udev rules was correct;
they are parsed and executed by udev correctly, and this is unlikely
to change. But systemd has enabled stricter checks in "udevadm verify"
to ensure better readability of udev rules files
(systemd/systemd#26980). This commit
makes sure the multipath-tools rules comply with these checks.

Signed-off-by: Dmitry V. Levin <ldv@strace.io>
Reviewed-by: Martin Wilck <mwilck@suse.com>

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 opensvc#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,
opensvc#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>