Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <000000000000f302fc057ea3b499@google.com> <000000000000557b4c0584cdabed@google.com>
 <20190325121635.GA10590@splinter>
In-Reply-To: <20190325121635.GA10590@splinter>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Tue, 26 Mar 2019 09:27:04 +0100
Message-ID: <CACT4Y+ai7ap_dKLetuZzfRC4VheZPWo=S=MB6J9a7_DHhTo0hw@mail.gmail.com>
Subject: Re: WARNING in bpf_prog_kallsyms_add
To:     Ido Schimmel <idosch@mellanox.com>
Cc:     syzbot <syzbot+987e48d84abddbe2506d@syzkaller.appspotmail.com>,
        "ast@kernel.org" <ast@kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "davem@davemloft.net" <davem@davemloft.net>,
        Jiri Pirko <jiri@mellanox.com>,
        "kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "syzkaller-bugs@googlegroups.com" <syzkaller-bugs@googlegroups.com>,
        "yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 25, 2019 at 1:16 PM Ido Schimmel <idosch@mellanox.com> wrote:
>
> + Dmitry
>
> On Sat, Mar 23, 2019 at 07:16:01PM -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 7607dd35fc34893214284cca740d015154d20452
> > Author: Ido Schimmel <idosch@mellanox.com>
> > Date:   Mon Jul 17 12:15:30 2017 +0000
> >
> >     mlxsw: spectrum: Trap IPv4 packets with Router Alert option
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14e0ac07200000
> > start commit:   645ff1e8 Merge branch 'for-linus' of git://git.kernel.org/..
> > git tree:       upstream
> > final crash:    https://syzkaller.appspot.com/x/report.txt?x=16e0ac07200000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12e0ac07200000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=20271e14bc1c87f0
> > dashboard link: https://syzkaller.appspot.com/bug?extid=987e48d84abddbe2506d
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13c69d20c00000
> >
> > Reported-by: syzbot+987e48d84abddbe2506d@syzkaller.appspotmail.com
> > Fixes: 7607dd35fc34 ("mlxsw: spectrum: Trap IPv4 packets with Router Alert
> > option")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> Dmitry,
>
> The bisection is probably wrong. Above mentioned commit is specific to
> mlxsw which is not even present in the provided kernel config.
>
> I see that this also appears in the web interface [1] which might be
> misleading to some people. Might be worthwhile to add a command for
> syzbot that tells it that bisection is wrong?
>
> [1] https://syzkaller.appspot.com/bug?id=b658eb696c8279d9951a4ceea79efba8a1d12467

Hi Ido,

Do you mean for the purposes of showing the results as "wrong" on the dashboard?

Generally the idea is that people can leave any free form comments on
the email thread associated with the bug (there is always a link from
the dashboard back to the email thread).  It's not possible to capture
all possible situations in a set of fixed tags. All information on the
dashboard may be incorrect in interesting ways. For example, consider
bisection diverged at the very last steps, so one may check the
bisection log and easily identify the commit that is most likely the
root cause, but the official result is off-by-one. Or may the free
stack in a use-after-free report is incorrect and then somebody may
suggest the right stack.

But having said that there is a proposal for custom tags for bugs
(e.g. for priority, subsystem, etc):
https://github.com/google/syzkaller/issues/608
And "bisection is wrong" may be a reasonable tag. I just don't want to
jump to a first ad-hoc implementation right now. I want to at least
try to thought out some consistent, extensible and useful design for
tagging.
I will add a note about bisection there.
Another concern is that I suspect very few people will actually use
it. Most people seem to tend to just drop a comment like "this is
fixed" or "syzbot sucks" without actually caring about any formal bug
state tracking...
But even if nobody will use it for majority of bugs, somebody (me)
still needs to design, implement, write tests, carefully deploy and
maintain this thing...

But thanks for the proposal!