Re: [PATCH v3 1/1] multipathd: don't leave maps read-only after write protect is cleared

[Benjamin Marzinski <bmarzins@redhat.com>]

On Mon, Oct 26, 2026 at 11:20:35PM +0100, Martin Wilck wrote:
> On Fri, 2026-10-23 at 19:40 -0400, Benjamin Marzinski wrote:
> > 
> > To solve this, whenever multipath detects that a device has switched
> > to
> > read-only, it forces a read-only table reload, so that all the path
> > devices get re-opened read-only (since their requested mode doesn't
> > match their current mode).
> 
> I am sorry, I guess I am just looking in the wrong place. But the way I
> read the code in dm_get_device() [1], the kernel will re-open a device
> only if the mode is upgraded, i.e. switched from ro to rw.
> 
> [1] https://elixir.bootlin.com/linux/v7.3/source/drivers/md/dm-table.c#L398
> 
> I don't see how a switch from rw to ro would cause a device to be
> reopened.

That only happens if find_device() already found that device in THIS
table (it's called with t->devices). For instance, the dm-delay table
can list the same device three times. Instead of opening the device 3
times, you just open it once.  Additionally, if you have already opened
the device in the current table in a mode that includes the capabilites
of the mode you need in a future call to dm_get_device() it will just
use the existing open. If you need more capabilites, you will upgrade
the open.

What matters in the multipath case is if the device isn't found in the
existing table. In that case you call dm_get_table_device(), which
calls find_table_device(). This looks for a device in the
md->table_devices list, which includes devices from all tables. But in
this case, the mode must match exactly
https://elixir.bootlin.com/linux/v7.3/source/drivers/md/dm.c#L807

Thinking about it now, I'm actually not sure if that upgrading from
dm_get_device() is a good thing. If a target asks to open multiple
copies of the same device with different modes, and dm gives it one open
that has a union of all the modes, it seems like we've dropped some
safety guardrails. I'm not sure off the top of my head if there actually
is a target that does this.

-Ben

> 
> Thanks
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck@suse.com>
> SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg,
> Germany
> Geschäftsführer: Stefan Gaiser, Jochen Jaser, Abhinav Puri (HRB
> 36809,AG Nürnberg)