On Fri, 2025-12-19 at 00:40 +0100, Martin Wilck wrote: > 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.
Thinking about it, I believe we should keep the call to check_removed_paths() in sync_paths(). We've put it there for a reason. We just need to be sure from where to call it. Martin
