Re: [PATCH v3 1/1] multipathd: check re-added paths' WWIDs against sysfs

[Benjamin Marzinski <bmarzins@redhat.com>]

On Mon, Nov 09, 2026 at 10:55:55AM -0800, Brian Bunker wrote:
> multipathd takes a path's WWID from udev. When a change uevent reports
> a different WWID, uev_update_path() removes the path from its map and
> re-adds it through uev_add_path(), which places it in whatever map owns
> the new WWID. If the udev value is wrong, or the uevent is stale by the
> time it is processed, the path goes into the map of a different LUN and
> I/O for one LUN is silently sent to another.
> 
> Before such a re-add puts the path into a map, compare its WWID with
> one built from the VPD page 0x83 data the kernel caches in sysfs. If
> they differ, leave the path out of the map: orphan it, clear its WWID
> and mark it INIT_MISSING_UDEV, so the checker retriggers udev and the
> path is re-added from fresh data. This reads no data from the device,
> so it can't hang. The check only runs for paths where
> can_recheck_wwid() is true, where the udev WWID and the one built from
> sysfs come from the same designator selection.
> 
> To tell re-adds from ordinary adds, turn the need_do_map argument of
> uev_add_path() and ev_add_path() into enum path_add_mode, with a new
> PATH_ADD_REINIT value that behaves like PATH_ADD_MAP and is passed only
> for the re-add at the end of uev_update_path(). Ordinary adds are
> unchanged.
> 
> Add get_sysfs_wwid() to libmultipath. It shares get_vpd_uid() and the
> WWID clean-up in get_uid() with the existing sysfs fallback, so both
> build the WWID the same way.
> 
> Signed-off-by: Brian Bunker <brian@purestorage.com>

I'm interested in seeing if this resolves Martin's issues, but as
far as I'm concerned:

Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>