From: Al Viro <viro@zeniv.linux.org.uk>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot <syzbot+31043da7725b6ec210f1@syzkaller.appspotmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: BUG: corrupted list in __dentry_kill (2)
Date: Thu, 12 Dec 2019 18:34:43 +0000 [thread overview]
Message-ID: <20191212183443.GH4203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CACT4Y+ZQ6C07TcuAHwc-T+Lb2ZkigkqW32d=TF054RuPwUFimw@mail.gmail.com>
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.
next prev parent reply other threads:[~2019-12-12 18:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 5:59 BUG: corrupted list in __dentry_kill (2) syzbot
2019-12-12 6:12 ` Al Viro
2019-12-12 6:48 ` Dmitry Vyukov
2019-12-12 13:38 ` Al Viro
2019-12-12 15:57 ` Dmitry Vyukov
2019-12-12 18:34 ` Al Viro [this message]
2019-12-13 9:10 ` Dmitry Vyukov
2019-12-12 11:35 ` syzbot
[not found] <20191212104355.24672-1-hdanton@sina.com>
2019-12-12 13:14 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191212183443.GH4203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dvyukov@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+31043da7725b6ec210f1@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).