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

[Benjamin Marzinski <bmarzins@redhat.com>]

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