[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjUrznUSUKN1AXQA9kCStQ3MHFY95ZmeTZ5zYDcvMhBiQ@mail.gmail.com>
Date: Sun, 17 Mar 2019 09:35:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: syzbot <syzbot+660883c56e2fa65d4497@...kaller.appspotmail.com>
Cc: David Miller <davem@...emloft.net>,
Johan Hedberg <johan.hedberg@...il.com>,
linux-bluetooth@...r.kernel.org,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Marcel Holtmann <marcel@...tmann.org>, mmarek@...e.com,
Netdev <netdev@...r.kernel.org>, syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: slab-out-of-bounds Read in bacpy
On Sun, Mar 17, 2019 at 3:43 AM syzbot
<syzbot+660883c56e2fa65d4497@...kaller.appspotmail.com> wrote:
>
> syzbot has bisected this bug to:
>
> commit c470abd4fde40ea6a0846a2beab642a578c0b8cd
> Author: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Sun Feb 19 22:34:00 2017 +0000
Heh. Yeah, I doubt it.
It would probably be good if syzbot did some confidence testing before
bisecting.
Don't get me wrong, "git bisect" is absolutely wonderful and has done
a ton to help us fix bugs, but bisection has one major downside: if
the bug you are bisecting isn't 100% repeatable, the bisection will go
off into the random weeds and give completely nonsensical results.
They won't even be *close*. What makes bisection so powerful is also
what makes it then completely random if there's even *one* mistaken
bisection point.
So it would probably be good to test each bisection point at least
twice, and if they don't agree, report it as being unbisectable rather
than give a random "this is what introduced the problem".
Hmm?
Linus
Powered by blists - more mailing lists