Message-ID: <CAKXUXMw2DqYFBzEpo-6F+_yOTY_+F88Tb_oK69ztkJWhQ72ZVA@mail.gmail.com>
Date:   Fri, 22 Jan 2021 07:02:33 +0100
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     慕冬亮 <mudongliangabcd@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, jirislaby@...nel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: "possible deadlock in console_lock_spinning_enable" and "possible
 deadlock in console_unlock" should be duplicate crash behaviors

On Fri, Jan 22, 2021 at 6:47 AM 慕冬亮 <mudongliangabcd@...il.com> wrote:
>
> On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn <lukas.bulwahn@...il.com> wrote:
> >
> > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 <mudongliangabcd@...il.com> wrote:
> > >
> > > Dear kernel developers,
> > >
> > > I found that on the syzbot dashboard, “possible deadlock in
> > > console_lock_spinning_enable”[1] and "possible deadlock in
> > > console_unlock"[2] should share the same root cause.
> > >
> > > The reasons for the above statement:
> > > 1) the stack trace is the same, and this title difference is due to
> > > the inline property of "console_lock_spinning_enable";
> > > 2) their PoCs are the same as each other;
> > >
> > > If you can have any issues with this statement or our information is
> > > useful to you, please let us know. Thanks very much.
> > >
> > > [1] “possible deadlock in console_lock_spinning_enable” -
> > > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0
> > > [2] “possible deadlock in console_unlock” -
> > > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
> > >
> > >
> >
> > Dongliang, what is the purpose of this activity?
>
> Lukas,
>
> We are conducting some research on the crash deduplication (or
> identifying unique bugs) of kernel crash reports. We would like to
> share some results from our research to facilitate the bugfix in the
> syzbot dashboard.
>
> >
> > Why do inform the kernel maintainers that two issues share the root cause?
> >
> > How does this activity contribute to fixing the bugs? Why does it
> > become easier to fix the issue/create a patch with the information you
> > provide?
>
> I do this for three reasons:
>
> (1) I think the reports sharing the same root cause may expedite the
> patching processing and help generate more complete patches. After
> patching bugs in one case, we can close the other cases quicker.
> Without these reports, one developer might be misled to develop an
> incomplete patch due to a lack of understanding of the underlying bug
> [1].
> (2) I think it might help maintainers to better assess the severity of
> the bug and thus could prioritize their effort.
> (3) Multiple reports might better help maintainers diagnose the bug's
> root cause.
>
> [1]  https://groups.google.com/g/syzkaller-bugs/c/9u_hEFvNbLw/m/CO9bfF8zCQAJ
>
> > (Honestly, I do not see how it does. I believe if anyone becomes
> > active and fixes the issue due to either one of the two reports, the
> > one report would be closed by the reported-by tag and the other report
> > would simply disappear after time because it could never be reproduced
> > and hence, syzbot would close it.)
> >
> > Would it not be more reasonable to fix issues rather than identifying
> > duplicates in the automatically filled and managed database?
>
> Yes, fixing issues or bugs is the ultimate goal. However, crash
> deduplication does benefit the bugfix process, and can reduce the
> heavy burden on the kernel developers. To make our analysis more
> useful, we will try our best to add some root cause analysis and how
> to fix the underlying bug.
>

Well, I am not really convinced, but I guess you will convince me when
(thanks to your feature) all bugs reported by syzbot are quickly fixed
and quickly closed.

good luck :)

Lukas

Powered by blists - more mailing lists