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 慕冬亮 wrote: > > On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn wrote: > > > > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 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
Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn wrote: > > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 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. > > Best regards, > > Lukas
Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 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? 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? (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? Best regards, Lukas
Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
On Thu, Jan 21, 2021 at 01:37:05PM +0800, 慕冬亮 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 Any proposed patch for these issues? thanks, greg k-h
"possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors
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 -- My best regards to you. No System Is Safe! Dongliang Mu