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.

-Ben

> 
> Martin


Reply via email to