[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+YAQGj6j+YJZuqGZYrDLYrY3K3sC1MOx9HvOJH=vbjxvQ@mail.gmail.com>
Date: Tue, 19 Dec 2017 14:54:24 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: syzbot
<bot+83f46cd25e266359cd056c91f6ecd20b04eddf42@...kaller.appspotmail.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
Hillf Danton <hillf.zj@...baba-inc.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Minchan Kim <minchan@...nel.org>, shakeelb@...gle.com,
syzkaller-bugs@...glegroups.com, ying.huang@...el.com,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in __list_del_entry_valid
On Tue, Dec 19, 2017 at 2:42 PM, Michal Hocko <mhocko@...nel.org> wrote:
> On Tue 19-12-17 14:38:35, Dmitry Vyukov wrote:
>> On Tue, Dec 19, 2017 at 2:22 PM, Michal Hocko <mhocko@...nel.org> wrote:
>> > On Tue 19-12-17 14:12:38, Dmitry Vyukov wrote:
>> >> On Tue, Dec 19, 2017 at 2:03 PM, Michal Hocko <mhocko@...nel.org> wrote:
>> >> > Can we silence this duplicates [1] please?
>> >> >
>> >> > [1] http://lkml.kernel.org/r/001a1140f57806ebef05608b25a5@google.com
>> >>
>> >> Hi Michal,
>> >>
>> >> What exactly do you mean?
>> >>
>> >> These 2 are the same email with the same Message-ID just on different
>> >> mailing lists. I don't see anything wrong here.
>> >
>> > Hmm the other one has Message-id: 001a1140f57806ebef05608b25a5@...gle.com
>> > while this one has 001a11452568f5857c0560b0dc0e@...gle.com
>>
>> Ah, I see.
>> These are reported separately because the crashes are titled
>> differently. Kernel titled one as "general protection fault" and
>> another as "BUG: unable to handle kernel NULL pointer dereference".
>
> Ahh, OK, so I've missed that part ;) I just thought it was duplicate
> because the report seemed very familiar.
>
>> What algorithm do you propose to use to merge them?
>
> Maybe based on the stack trace?
You are subscribing to _lots_ of mail ;)
syzbot has reported 250 bugs in 2 months:
https://groups.google.com/forum/#!forum/syzkaller-bugs
with stacks it will be thousands and that will produce lots of other
duplicates (same functionality accessible from different stacks).
Also, linux kernel does not allow reliable stack extraction since it
doesn't stop other CPUs, frequently reports look as complete
intermixed mess with lines coming from different reports, lines split
in half, etc. To rely on stacks we need to be able to _very_ reliably
extract whole stack, but it's hardly possible today.
Powered by blists - more mailing lists