On Fri, Sep 23, 2022 at 4:35 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2022/09/23 20:58, Aleksandr Nogikh wrote: > > We do have plans to start inspecting LKML messages for the patches > > that mention syzbot-reported bugs. It will be possible then to display > > them all on the bug page and somehow mark bugs with a PATCH sent on > > the list. > > I interpret it as an attempt to automatically show "Patch proposed" state. > But since not all patches have Reported-by: tag, and/or a proposed patch > with Reported-by: tag might be withdrawn via review, that state should be > also manually changeable. Yes, it is meant to be manually changeable. To be honest, I'm a little bit worried about making the syzbot communication protocol more and more complex - e.g. how will other developers figure out that such a feature exists at all.. Though, there are anyway no other options than to extend the protocol. > > > And then syzbot should just display all such received comments on the > > bug's web page, right? > > Whether "all comments" or "last comment" needs some decision. It might be a few words > indicating culprit subsystem (probably "last" should overwrite), it might be memo > describing how far debugging went (probably "all" is helpful), it might be some > URL where discussions/patches are (probably "all" is helpful), it might be trying to > show or hide "Patch proposed" state (probably "last" should overwrite). > It seems that even displaying all patch sending attempts (regardless of their status) should be already very helpful in preventing the situations like you described earlier. E.g. it's very likely that syzbot won't be promptly notified about withdrawn patches, so it's anyway necessary to look at all previous attempts. > > > By the way, a possible improvement on "Patch testing requests:" table. > Although the "Patch" link showing diff output after applying proposed patch is OK, > I'd like to also see a link to original "#syz test:" mail, for the intent of diff > (which would be in patch description part if it was a formal patch) is dropped from > diff output in the "Patch" link. Interesting! I created an issue to keep track of this: https://github.com/google/syzkaller/issues/3392 The presence of the link will, though, depend on whether the user did Cc some public mailing lists while making the patch testing request. > > For example, https://syzkaller.appspot.com/bug?extid=9ca7a12fd736d93e0232 was forgotten > for 1000 days after 7 patch testing requests. I can't easily find the intent of each diff > (e.g. just debug printk() or proper fix). It seems the last one was about to formal submit, > but I can't find why it is not yet applied. Btw there was recently deployed an old repro retesting feature that retests old reproducers and obsoletes bugs if all of them are no longer working. It has already closed > 150 bugs this way (more to come) and in quite a lot of such closed bugs I see a patch testing request from some developer that was done several months or even several years ago. And syzbot was not notified about these fixes. So yes, the presence of a patch testing request can be a strong indicator that the bug is already fixed and syzbot just doesn't know about that. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@xxxxxxxxxxxxxxxx. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/ea7c00c1-07d7-c23e-80f0-0693016e9731%40I-love.SAKURA.ne.jp.
