dashboard/app: custom tags for bugs

[dvyukov]

Proposed on mailing list as "Column for keywords?": https://groups.google.com/d/msg/syzkaller/SD0DZkuIXBU/4Ozmm12ACAAJ Filing this to not lose track of the proposal.

[dvyukov]

Another idea by Ido: https://groups.google.com/d/msg/syzkaller-bugs/79fgOLAX5co/kZnbgbG5BQAJ is to use tags to mark incorrect bisection and then show it on the bug page. Tags could also capture reason for incorrect bisection.

[dvyukov]

FTR, Debian bug tracker is fully-email-based full-fledged bug tracking system: https://www.debian.org/Bugs/ We could look at features for inspiration of what may be useful, and maybe reuse some actual command syntax (if we like it) to not invent something completely new: https://www.debian.org/Bugs/server-control https://www.debian.org/Bugs/server-request https://www.debian.org/Bugs/Developer

[dvyukov]

Another data point: NetBSD people want

Consistency and relevance of the "fixed bugs" history, so that we can get
a clear view of the most common types of bugs and mistakes without being
drowned in one-off stuff. For statistical purposes.

https://groups.google.com/d/msg/syzkaller/WDiHEcKVZWc/9RhdKVJPGwAJ

This can only be decided on manually. Currently we have to mark a number of fixed bugs as invalid to get them off the fixed bugs page.

This can be classified with a single "fixed one-off" tag.

[melver]

Another usecase would be to tag bugs that are not actionable right now. For KCSAN, a lot of bugs are quite low priority, and it would be useful to simply classify bugs based on priority, and e.g. hide bugs that are tagged as low priority.

The other usecase for KCSAN would be classifying the type of race (ops involved, etc.), which can be useful to understand clusters of races better, or alternatively use to prioritize better.

[novitoll]

Hello @dvyukov ,

Proceeding the conversation here, please let me know if this should be discussed in Google groups, thought with screenshots, it would be better here.

TL;DR: These are just mockups of what I would like to see, havent thought on implementation part yet. So theoretically only :)

I tried to collect all points in these mockups, and some of them addressed with UI only solution:

• [x] custom keywords: https://groups.google.com/g/syzkaller/c/SD0DZkuIXBU/m/t9W3CiSECAAJ

1. Collecting/showing subsystem was already proposed by Guenter Roeck: https://github.com/google/syzkaller/issues/544

Showing subsystem in the main Table page at the last column as Tags can be multiple, so they fit to the single row, unless new column is appeared. Tags are auto-generated by syzbot, need to write a script to generate for existing reports. Tags can be:

• netdev, linux-media etc., e.g. retrieved from MAINTAINERS list and pick only mailing group, not personal emails as tags (??)
• bpf-repro -- if repro contains syscall(__NR_bpf to trigger the bug. Can be useful for categorizing such repros.
• race-repro or just race -- if KCSAN triggered the bug, or repro contains pthreads indicating that race condition might be the issue
• warning or bugon -- that this is the oops bug, however the title already has WARNING: .. which can be "filtered" via Ctrl +F or using new search bar

• [ ] manual tagging: https://groups.google.com/g/syzkaller/c/SD0DZkuIXBU/m/hFLDuOjWCAAJ

My concern is how to "manually compensate things" where automatic processing is failing. Automatic tagging becomes valuable and less burden on humans only if it is tagged appropriately. I want manual tagging.

Not addressed.

• [ ] current status: same message thread

For describing current status. Possibly including trivial mumble like "$(MyName) is analyzing now" which do not worth spamming LKML.

Not addressed.

• [x] filter / search on frontend side reports on the main Table page: https://groups.google.com/g/syzkaller/c/PB_IEUKY1Fc

[dvyukov]

• @tarasmadan