[PATCH 0/1] multipath: fix "multipath -f <path>" regression since 0.9.8

[PATCH 0/1] multipath: fix "multipath -f <path>" regression since 0.9.8

[Brian Bunker]

Since 0.9.8, "multipath -f" fails with "device not found" when it is
given a path to a map, such as /dev/mapper/<alias> or
/dev/disk/by-id/dm-uuid-mpath-<WWID>, while multipathd is running.
This patch fixes it in the multipath command. Some background that
doesn't belong in the commit message:

How it was found
----------------
OpenStack os-brick's Fibre Channel connector detaches a volume with
"multipath -f /dev/disk/by-id/dm-uuid-mpath-<WWID>". Every FC detach
fails on distributions with multipath-tools 0.9.8 or later, including
RHEL/Rocky 10 (0.9.9), Debian 13 and Ubuntu 26.04 (0.14.3), the tested
platform for the next OpenStack release. It is tracked as
https://bugs.launchpad.net/os-brick/+bug/2167932. os-brick is adding
a workaround, but fixing "multipath -f" also covers existing os-brick
releases and other tools that remove maps by path.

Why in the client
-----------------
Commit a4dbdcec made cli_del_map() look up maps with find_mp_by_str(),
like the other client handlers, so I didn't want to bring device-mapper
lookups back into multipathd. get_dev_type() has already stat()ed the
argument, so the client can resolve it to the map name before it
delegates. This leaves "multipathd del map <path>" unsupported. If
you'd rather have multipathd accept paths, I can rework the patch that
way.

Testing
-------
Rocky Linux 10.2, device-mapper-multipath 0.9.9-18.el10 with this
patch on top (it applies cleanly after the RHEL patches), a PURE
FlashArray LUN over iSCSI, multipathd running:

- "multipath -f /dev/disk/by-id/dm-uuid-mpath-<WWID>" and
  "multipath -f /dev/mapper/<WWID>" fail with "device not found"
  without the patch and remove the map with it.
- "multipath -f <WWID>" works as before; the argument isn't changed.

multipathd's log, before and after, for the by-id path:

  disk/by-id/dm-uuid-mpath-44BE9D5DF0A14AFE000113E9: remove map (operator)
  disk/by-id/dm-uuid-mpath-44BE9D5DF0A14AFE000113E9: invalid map name.
  44BE9D5DF0A14AFE000113E9: remove map (operator)

On master, the patch builds without warnings and "make test" passes.

The regression is in every release since 0.9.8, so this may be worth
picking up for the stable branches.

Brian Bunker (1):
  multipath: resolve map paths before delegating -f to multipathd

 multipath/main.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

-- 
2.55.0

[PATCH 1/1] multipath: resolve map paths before delegating -f to multipathd

[Brian Bunker]

Since 0.9.8, "multipath -f" fails with "device not found" when it is
given a path to a map, such as /dev/mapper/<alias> or
/dev/disk/by-id/dm-uuid-mpath-<WWID>, and multipathd is running.

get_dev_type() accepts such a path as DEV_DEVMAP, because it stat()s
to a device-mapper block device, and delegate_to_multipathd() sends
it unchanged as "del map <path>". cli_del_map() only strips a leading
"/dev/", and find_mp_by_str() only matches an alias, a WWID or a dm-N
name, so the map is not found. Before commit a4dbdcec, cli_del_map()
looked the argument up with dm_get_major_minor(), which accepted any
path to the device. And before commit 8c0c12ef, a failed delegation
fell back to a local flush, which also resolves paths.

This breaks callers that remove maps by path. OpenStack os-brick's
Fibre Channel connector flushes /dev/disk/by-id/dm-uuid-mpath-<WWID>
on every volume detach, so detach works on RHEL 9 (0.8.7 based) and
fails on RHEL 10 (0.9.9 based).

If the -f argument is a path, resolve it to the map name with
dm_mapname() before delegating. The local flush, used when multipathd
is not running, gets the same name. Arguments that are valid map
names are passed through unchanged.

Fixes: a4dbdcec ("multipathd: simplify cli_del_map()")
Reported-by: Simon Dodsley <simon@purestorage.com>
Signed-off-by: Brian Bunker <brian@purestorage.com>
---
 multipath/main.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/multipath/main.c b/multipath/main.c
index f20d701c..5068a659 100644
--- a/multipath/main.c
+++ b/multipath/main.c
@@ -729,6 +729,30 @@ get_dev_type(char *dev) {
 	return DEV_NONE;
 }
 
+/*
+ * multipathd resolves "del map $map" arguments by alias, WWID or dm-N
+ * name, not by device path. If a map was passed as a path, e.g.
+ * /dev/mapper/$alias or /dev/disk/by-id/dm-uuid-mpath-$WWID, replace it
+ * with the map name.
+ */
+static void
+resolve_devmap_path(char *dev)
+{
+	struct stat buf;
+	char __attribute__((cleanup(cleanup_charp))) *name = NULL;
+
+	if (valid_alias(dev) || stat(dev, &buf) != 0 ||
+	    !S_ISBLK(buf.st_mode))
+		return;
+
+	name = dm_mapname(major(buf.st_rdev), minor(buf.st_rdev));
+	if (!name)
+		return;
+
+	condlog(3, "%s: using map name %s", dev, name);
+	strlcpy(dev, name, FILE_NAME_SIZE);
+}
+
 /*
  * Some multipath commands are dangerous to run while multipathd is running.
  * For example, "multipath -r" may apply a modified configuration to the kernel,
@@ -1027,6 +1051,8 @@ main (int argc, char *argv[])
 		condlog(0, "the -f option requires a map name to remove");
 		goto out;
 	}
+	if (cmd == CMD_FLUSH_ONE)
+		resolve_devmap_path(dev);
 
 	while (1) {
 		int ret = delegate_to_multipathd(cmd, dev, dev_type, conf);
-- 
2.55.0

Re: [PATCH 1/1] multipath: resolve map paths before delegating -f to multipathd

[Benjamin Marzinski]

On Mon, Sep 28, 2026 at 09:54:43AM -0700, Brian Bunker wrote:
> --- a/multipath/main.c
> +++ b/multipath/main.c
> @@ -729,6 +729,30 @@ get_dev_type(char *dev) {
>  	return DEV_NONE;
>  }
>  
> +/*
> + * multipathd resolves "del map $map" arguments by alias, WWID or dm-N
> + * name, not by device path. If a map was passed as a path, e.g.
> + * /dev/mapper/$alias or /dev/disk/by-id/dm-uuid-mpath-$WWID, replace it
> + * with the map name.
> + */
> +static void
> +resolve_devmap_path(char *dev)
> +{
> +	struct stat buf;
> +	char __attribute__((cleanup(cleanup_charp))) *name = NULL;
> +
> +	if (valid_alias(dev) || stat(dev, &buf) != 0 ||
> +	    !S_ISBLK(buf.st_mode))
> +		return;
> +
> +	name = dm_mapname(major(buf.st_rdev), minor(buf.st_rdev));
> +	if (!name)
> +		return;
> +
> +	condlog(3, "%s: using map name %s", dev, name);
> +	strlcpy(dev, name, FILE_NAME_SIZE);
> +}
> +
>  /*
>   * Some multipath commands are dangerous to run while multipathd is running.
>   * For example, "multipath -r" may apply a modified configuration to the kernel,
> @@ -1027,6 +1051,8 @@ main (int argc, char *argv[])
>  		condlog(0, "the -f option requires a map name to remove");
>  		goto out;
>  	}

Thanks for the fix. This looks good, although I wonder if we should
always update dev for a DEV_DEVMAP type device that we can stat(),
likely in get_dev_type(). That would keep us from needing to deal with
this again if we delegate anything else to multipathd. Thoughts, Martin?
Otherwise, I'm fine with this as is.

-Ben 

> +	if (cmd == CMD_FLUSH_ONE)
> +		resolve_devmap_path(dev);
>  
>  	while (1) {
>  		int ret = delegate_to_multipathd(cmd, dev, dev_type, conf);
> -- 
> 2.55.0