Date:   Mon, 20 May 2019 16:22:49 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        syzbot <syzbot+73c7fe4f77776505299b@...kaller.appspotmail.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, sabin.rapan@...il.com,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: BUG: unable to handle kernel paging request in do_mount

On Sat, May 18, 2019 at 11:41 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> > > What would you prefer to happen in such situations?  Commit summaries
> > > modified enough to confuse CI tools into *NOT* noticing that those
> > > are versions of the same patch?  Some kind of metadata telling the
> > > same tools that such-and-such commits got folded in (and they might
> > > have been split in process, with parts folded into different spots
> > > in the series, at that)?
> > >
> > > Because "never fold in, never reorder, just accumulate patches in
> > > the end of the series" is not going to fly.  For a lot of reasons.
> >
> > As far as I'm concerned, this is the tools problem; I don't think it's
> > worth it for developers to feel they need to twist themselves into
> > knots just to try to make the CI tools' life easier.
>
> FWIW, what _is_ the underlying problem?  It looks like the basic issue
> is with rebase/cherry-pick of a commit; it seems to be trying to
> handle two things:
>         1) report X' in commit C' is similar to report X in commit C,
> with C' apparently being a rebase/cherry-pick/whatnot of C; don't
> want to lose that information
>         2) reports X, Y and Z in commit C don't seem to be reoccuring
> on the current tree, without any claimed fix in it.  Want to keep
> an eye on those.
>
> ... and getting screwed by a mix of those two: reports X, Y and Z in
> commit C don't seem to be reoccuring on the current tree, even though
> it does contain a commit C' that seems to be a rebase of C.  A fix for
> C is *not* present as an identifiable commit in the current tree.
> Was it lost or was it renamed/merged with other commits/replaced by
> another fix?
>
> What I don't quite understand is why does the tool care.  Suppose
> we have a buggy commit + clearly marked fix.  And see a report
> very similar to the original ones, on the tree with alleged fix
> clearly present.  IME the earlier reports are often quite relevant -
> the fix might have been incomplete/racy/etc., and in that case
> the old reports (*AND* pointer to the commit that was supposed to
> have fixed those) are very useful.
>
> What's the problem these reminders are trying to solve?  Computational
> resources eaten by comparisons?

syzbot, as any bug tracking system has notion of "open" and "closed"
bugs. This is useful for 2 main reasons:
 - being able to see what are the currently open bugs (on our plate)
to not go over already closed bugs again and again and to not lose
still relevant bugs (for upstream linux
https://syzkaller.appspot.com/upstream#open)
 - to be able to understand when a new similarly looking crash is
actually a new bug (either not completely fixed old one, or completely
new does not matter much) and report it again (because it's not a good
idea to send an email for every crash as is (hundreds of thousands a
day))

In order to do this tracking syzbot needs the association between
reports and fixing commits. Merely saying "it's fixed" is not enough
because consider you say "it's fixed", but it's fixed only in mm, but
not in net-next. So next second syzbot sees this crash again in
net-next and sends a new bug report as it now thinks the old one is
fixed, so this must be a new one. Only the commit allows it to
precisely understand when the fix is in all trees, and not just in all
trees but in all currently tested builds for these trees.

Above you say "on the tree with alleged fix clearly present". To
understand that syzbot needs to know the commit.

Powered by blists - more mailing lists