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 <[email protected]>
I'm interested in seeing if this resolves Martin's issues, but as far as I'm concerned: Reviewed-by: Benjamin Marzinski <[email protected]>
