On Thu, 2025-12-18 at 18:34 -0500, Benjamin Marzinski wrote: > On Wed, Dec 17, 2025 at 10:20:55PM +0100, Martin Wilck wrote: > > Modifying the pathvec in a deep call stack is unexpected and > > error-prone. Free paths in the checkerloop instead, after > > having synced all maps. > > I'm not fond of the fact that this leaves paths around, when callers > expect that the path will be removed. For instance, right now > cli_add_path() and uev_add_path() can call ev_remove_path to handle > INIT_REMOVED paths, and expect that success means the path is > removed.
Thanks for pointing this out. > They can end up storing duplicate paths with this code. I'm not sure if that really hurts, as long as multipathd basically ignores INIT_REMOVED paths, and eventually frees them. But I agree that it's awkward and should be avoided if possible. > What do you think about having calls to ev_remove_path() actually > remove > the path if multipath device successfully orphans it. Sure, that should be possible. I'll think about it. I just want to stop removing paths somewhere deep in the stack. Thanks, Martin
