syz-ci: poll lore mailing list archives for pending fixes

[dvyukov]

Sometimes a fix is posted to a kernel mailing list, but then either (1) it gets lost, or (2) somebody else spends time to fix the same bug again without being aware of the existing fix. One precedent: https://groups.google.com/forum/#!topic/syzkaller-bugs/ilAjLbsyV0A

We could poll mailing list archives from https://lore.kernel.org/lists.html stored in git to discover pending fixes and notify dashboard. This will also have some synergy with bug notifications about pending fixes: #1574 Will this need a special type of association between bugs and commits? Or we could simply upload it as normal fixing commit?

[melver]

There is a caveat here: If a patch fixes a problem, but the patch is ignored because it's either the wrong fix, duplicate, or poor quality, then it needs to be ignored. But unfortunately there is no information to derive this; in the worst case, because the only place this information exists is in a maintainer's head (or some other database they maintain).

The only way to make this useful, is to collect all posted patches and categorize them as "proposed" -- I think this might sort of answer your questions "[...] special type of association [...]?" and "[...] upload it as normal fixing commit?".

In other words, the patches could be acknowledged and tracked, but only displayed as a separate list of "potential fixes". This might provide value, since it might allow someone encountering the same problem, to quickly pick a fix (although they might have several patches/versions to choose from).

[thazhemadam]

Generally, a patch with a fix (or even a potential fix - even if it is incorrect) that gets sent to the mailing lists has the syzbot address (from the Reported-by tag) CCed. If possible, this could be used for acknowledging and tracking the patches.

Also, adding to what @melver said, it might also help to provide a feature for users who have already started working on a bug (or are about to) to make it known that they will be working on the bug too. syzbot provides a sign-in option where users can sign in using their email-ids. Users could sign in and "mark" a bug if they're going to be working on it/have already fixed it, and this would be visible to all others who visit the bug's page on the dashboard.

This "mark" could also be extended indicate at least one of 3 things (which can each be identified with a simple colored dot) -

1. "I want to work on this bug, but I am still in the process of understanding it better."
2. "I understand the bug, and have a fair idea about what to do. But my potential fix needs to be tested, and reviewed."
3. "I know what's going on, and I have a fix."

Granted this would require people to visit the dashboard more than most people care for (since a lot of them work directly off of the syzbot mail), but at least this way people know who else are working on a fix/if a fix has already been submitted, and check that out too in a more real-time manner.

[dvyukov]

syzbot provides a sign-in option where users can sign in using their email-ids. Users could sign in and "mark" a bug if they're going to be working on it/have already fixed it, and this would be visible to all others who visit the bug's page on the dashboard.

This is outside of the scope of the project for 2 reasons:

1. This is a slippery slope to implementing a full-fledged bug tracking system. Once people can do these actions, they will also want marking bugs as fixed, submitting tests requests and all other actions. Building a full-fledged bug tracking system requires 10x more developer resources that is currently allocated on syzbot (look at Bugzilla/Mantis/Jira) and there is not point in spending resources at implementing yet another one. Moreover, use of Bugzilla is discouraged for Linux kernel.
2. All of this is not specific to syzbot and is relevant to all other kernel bugs. syzbot should not invent own ways of solving these problems, and the ways that are not helpful for kernel bugs reported by other entities (low return of investment). syzbot should use whatever is the current kernel's way of dealing with these problems. As you noted, some kernel developers won't even use some external web service.

[a-nogikh]

A related user request:

# I wish that syzbot dashboard allows manually specifying e.g. "patch proposed" state, for
# some patches take long time before accepted (and may result in duplicated works like I did
# on this bug).

https://groups.google.com/g/syzkaller-bugs/c/ysjnCmKu6Dc/m/94C76byKBQAJ

[a-nogikh]

Closing the bug since LKML parsing was already implemented and deployed on syzbot.

No notifications are set up yet, but that's to be tracked in https://github.com/google/syzkaller/issues/1574