linux-kernel - Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <914a7e9207c028a74d5c579273b4c71b555619d7.camel@suse.com>
Date: Wed, 28 May 2025 22:44:16 +0200
From: Martin Wilck <mwilck@...e.com>
To: Christoph Hellwig <hch@...radead.org>, Benjamin Marzinski
	 <bmarzins@...hat.com>
Cc: Kevin Wolf <kwolf@...hat.com>, dm-devel@...ts.linux.dev,
 hreitz@...hat.com, 	mpatocka@...hat.com, snitzer@...nel.org,
 linux-kernel@...r.kernel.org, Hannes Reinecke <hare@...e.com>
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active
 paths

On Sun, 2025-05-18 at 22:32 -0700, Christoph Hellwig wrote:
> On Fri, May 16, 2025 at 12:06:21PM -0400, Benjamin Marzinski wrote:
> > I've run into SCSI arrays that always act like they were called
> > with the
> > ALL_TG_PT flag set (or perhaps they were just configured that way,
> > I
> > never could get a straight answer about that).
> 
> Hmm, that's pretty strange.
> 
> > libmpathpersist accepts
> > this flag, and only sends one registration per initiator & target
> > device
> > when it's set, instead of one per initator & target port.
> 
> With "this flag" you mean ALL_TG_PT?

multipath-tools allows setting the flag "all_tg_pt" in multipath.conf
for certain storage devices or multipath maps. If this flag is set,
mpathpersist will always act as if the --param-alltgpt flag was given.
This means that the REGISTER commands are sent once per initiator port
(SCSI host) only, instead of once per I_T nexus.

By default, the all_tg_pt flag is not set for any device, not even for
EMC VNX, where Ben observed the described behavior. It seems that
devices that behave like this are a rare exception.

> > dm-multipath
> > currently doesn't have the knowledge necessary to figure out which
> > devices it needs to send reservations to, even if the kernel PR API
> > supported this.
> > 
> > But I supposed it could just send the registration normally down
> > one
> > path and if that works, it could just ignore the existing key when
> > it
> > sends the registration down all the other paths.
> 
> We could add support for a similar flag to the kernel PR API.  The
> problem is to figure out how to discover support for it.  What does
> the library do for that currently?

dm-multipath has no knowledge about target or initiator ports, and I
fail to see how we could provide this knowledge to it without adding
yet another layering violation. Just sending the command once will not
be sufficient if there are multiple local ports.

Regards
Martin