On Sat, Jul 27, 2019 at 4:29 AM Linus Torvalds <torva...@linux-foundation.org> wrote: > > On Fri, Jul 26, 2019 at 4:26 PM syzbot > <syzbot+ad8ca40ecd77896d5...@syzkaller.appspotmail.com> wrote: > > > > syzbot has bisected this bug to: > > > > commit 0e034f5c4bc408c943f9c4a06244415d75d7108c > > Author: Linus Torvalds <torva...@linux-foundation.org> > > Date: Wed May 18 18:51:25 2016 +0000 > > > > iwlwifi: fix mis-merge that breaks the driver > > While this bisection looks more likely than the other syzbot entry > that bisected to a version change, I don't think it is correct eitger. > > The bisection ended up doing a lot of "git bisect skip" because of the > > undefined reference to `nf_nat_icmp_reply_translation' > > issue. Also, the memory leak doesn't seem to be entirely reliable: > when the bisect does 10 runs to verify that some test kernel is bad, > there are a couple of cases where only one or two of the ten run > failed. > > Which makes me wonder if one or two of the "everything OK" runs were > actually buggy, but just happened to have all ten pass...
I agree this is unrelated. Bisection of memory leaks is now turned off completely after a week-long experiment (details: https://groups.google.com/d/msg/syzkaller/sR8aAXaWEF4/k34t365JBgAJ) FWIW 'git bisect skip' is not a problem in itself. If the bisection will end up being inconclusive due to this, then syzbot will not attribute it to any commit (won't send an email at all), it will just show the commit range in the web UI for the bug. Low probability wasn't the root cause as well, first runs ended with 10/10 precision: bisecting cause commit starting from 3bfe1fc46794631366faa3ef075e1b0ff7ba120a building syzkaller on 1656845f45f284c574eb4f8bfe85dd7916a47a3a testing commit 3bfe1fc46794631366faa3ef075e1b0ff7ba120a with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs testing release v5.2 testing commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs testing release v5.1 testing commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs testing release v5.0 testing commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs testing release v4.20 testing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs testing release v4.19 testing commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d with gcc (GCC) 8.1.0 all runs: crashed: memory leak in kobject_set_name_vargs But it was distracted by other bugs and other memory leaks (which reproduce with lower probability) and then the process went random (which confirms the bisection analysis results).
