Re: BUG: corrupted list in __dentry_kill (2)

[Al Viro]

On Thu, Dec 12, 2019 at 04:57:14PM +0100, Dmitry Vyukov wrote:

> > Speaking of bisect hazards, I'd recommend to check how your bisect
> > went - the bug is definitely local to this commit and I really
> > wonder what had caused the bisect to go wrong in this particular
> > case.
> 
> I did not get the relation of folding to bisection. Or you mean these
> are just separate things?

Suppose instead of folding the fix in I would've done a followup commit
just with the fix.  And left the branch in that form, eventually getting
it pulled into mainline.  From that point on, *ANY* bisect stepping into
the first commit would've been thrown off.  For ever and ever, since
once it's in mainline, it really won't go away.

That's what folding avoids - accumulation of scar tissue, if you will.
Sure, there's enough cases when bug is found too late - it's already
in mainline or pulled into net-next or some other branch with similar
"no rebase, no reorder" policy.  But if you look at the patchsets posted
on the lists and watch them from iteration to iteration, you'll see
a _lot_ of fix-folding.  IME (both by my own practice and by watching
the patchsets posted by others) it outnumbers the cases when fix can't
be folded by quite a factor.  I wouldn't be surprised if it was an
order of magnitude...

Strict "never fold fixes" policy would've accelerated the accumulation
of bisect hazards in the mainline.  And while useful bisect may be a lost
cause for CI bots, it isn't that for intelligent developers.  Anything
that makes it more painful is not going to be welcome.