* Re: memory leak in kobject_set_name_vargs (2)
2019-07-27 2:29 ` Linus Torvalds
@ 2019-07-27 2:56 ` Qian Cai
2019-08-08 17:04 ` Dmitry Vyukov
1 sibling, 0 replies; 4+ messages in thread
From: Qian Cai @ 2019-07-27 2:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: syzbot, Catalin Marinas, David Miller, Dmitry Vyukov, Herbert Xu,
kuznet, Kalle Valo, Linux List Kernel Mailing, Linux-MM,
luciano.coelho, Netdev, steffen.klassert, syzkaller-bugs,
yoshfuji, Wang Hai, Andy Shevchenko, David S. Miller
> On Jul 26, 2019, at 10:29 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Fri, Jul 26, 2019 at 4:26 PM syzbot
> <syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
>>
>> syzbot has bisected this bug to:
>>
>> commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
>> Author: Linus Torvalds <torvalds@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…
Real bisection should point to,
8ed633b9baf9e (“Revert "net-sysfs: Fix memory leak in netdev_register_kobject”")
I did encounter those memory leak and comes up with a similar fix in,
6b70fc94afd1 ("net-sysfs: Fix memory leak in netdev_register_kobject”)
but those error handling paths are tricky that seems nobody did much testing there, so it will
keep hitting other bugs in upper functions.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: memory leak in kobject_set_name_vargs (2)
2019-07-27 2:29 ` Linus Torvalds
2019-07-27 2:56 ` Qian Cai
@ 2019-08-08 17:04 ` Dmitry Vyukov
1 sibling, 0 replies; 4+ messages in thread
From: Dmitry Vyukov @ 2019-08-08 17:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: syzbot, Catalin Marinas, David Miller, Herbert Xu,
Alexey Kuznetsov, Kalle Valo, Linux List Kernel Mailing,
Linux-MM, luciano.coelho, Netdev, Steffen Klassert,
syzkaller-bugs, Hideaki YOSHIFUJI
On Sat, Jul 27, 2019 at 4:29 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Jul 26, 2019 at 4:26 PM syzbot
> <syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 0e034f5c4bc408c943f9c4a06244415d75d7108c
> > Author: Linus Torvalds <torvalds@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).
^ permalink raw reply [flat|nested] 4+ messages in thread