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
