linux-kernel - Re: BUG: corrupted list in __dentry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACT4Y+b7hZuNuc4sRnhFkpCw+xQg2hzX1WuD__rejigxzBpXBg@mail.gmail.com>
Date:   Fri, 13 Dec 2019 10:10:25 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     syzbot <syzbot+31043da7725b6ec210f1@...kaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: BUG: corrupted list in __dentry_kill (2)

On Thu, Dec 12, 2019 at 7:34 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> 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.


Ah, I see. Yes, folding will help future bisections. In fact, an
unfolded bug somewhere in kernel history is exactly what caused wrong
result on bisection for this bug.
Just in case, I did not propose to not do folding here (or anywhere
else as far as I remember). Handling of folded fixes is documented in
syzbot docs:
https://goo.gl/tpsmEJ#rebuilt-treesamended-patches