On Tue, 2025-09-30 at 19:53 -0400, Benjamin Marzinski wrote: > If a multipath device gets preempted while a path is being restored, > the > path could end up getting the old key registered on it anyways. This > happens by: > 1. multipathd calling update_map_pr() in mpath_pr_event_handle() and > seeing that there are matching keys. > 2. Those matching keys get preempted. > 3. multipathd registering the preempted key on the path. > > Since there is no way to guarantee that the key won't get preempted > after multipathd checks for it, mpath_pr_event_handle() now calls > update_map_pr() to check the registered keys again after registering > the > key. There must be at least as many keys registered after registering > the key on the restored path (which may already have a key registered > on > it, so it's possible that the number of registered keys doesn't > change). > > pr_register_active_paths() calls mpath_pr_event_handle() for all > working > paths on a device. In order to avoid calling update_map_pr() twice > for > every path, mpath_pr_event_handle() now takes the number of keys to > expect, and skips the initial call to update_map_pr() if it already > knows how many keys are registered before trying to register the new > path. > > Signed-off-by: Benjamin Marzinski <[email protected]>
Reviewed-by: Martin Wilck <[email protected]>
