On Tue, 2024-07-16 at 10:52 -0400, Benjamin Marzinski wrote: > On Mon, Jul 15, 2024 at 06:00:33PM +0200, Martin Wilck wrote: > > On Sat, 2024-07-13 at 02:04 -0400, Benjamin Marzinski wrote: > > > When handle_uninitialized_path() checks a path, it will either: > > > 1. trigger a new uevent to initalize the path, in which case it > > > won't > > > check the path again until that uevent is processed and > > > updates > > > pp->tick > > > 2. blacklist the path, in which case the path gets removed > > > 3. intialize the path correctly, in which case it sets pp->tick = > > > 1 > > > 4. fail to initialize the path, in which case it was supposed to > > > set > > > pp->tick to max_checkint, but instead it set pp->checkint to > > > max_checkint, which never worked correctly. > > > > > > By setting pp->tick to max_checkint at the start, > > > handle_uninitialized_path() will continue to work as it > > > previously > > > did, > > > except in case 4, where in now works correctly. There's no point > > > in > > > messing with pp->checkint for paths that haven't been initialized > > > yet. > > > > > > Signed-off-by: Benjamin Marzinski <[email protected]> > > > > Reviewed-by: Martin Wilck <[email protected]> > > > > Q: I suppose it makes sense to backport this to earlier releases? > > It's not a horrible bug. Previously, we set pp->tick to checkint > early > in the function. This just means that these problematic paths will > be checked every checkint instead of every max_checkint. > > Also, do you mean distros backporting this change? I'm not sure how > much value there is in maintaining upstream stable branches.
Yes, I was referring to distro backporting. I don't want to start stable branches upstream, although we've had several cases where I thought it might be worth it. Martin
