On 2018/06/27 5:37, Tetsuo Handa wrote: > I think that syzbot can stop deciding email recipients and leave it to those > who > diagnose bugs, for the ratio of sending to wrong subsystem maintainers is not > low. > For example, syzbot assumed that "INFO: task hung in __get_super" is a fs > layer bug. > But I think that the problem is in more lower layers (block or mm or locking > layer). > The root cause could even be just overstressed due to instructions enabled by > CONFIG_KCOV_ENABLE_COMPARISONS=y. >
Thinking from today's bpf related reports, I think that subversion/quilt-based custom patches will be useful as well. Since quilt can apply changes in a patch atomically (using "quilt push" command), we can maintain one custom patch for one git tree. Then, the kernel source syzbot will test is either "no custom patch applied" or "only one custom patch applied". That is, if "quilt push" fails, syzbot will continue testing without custom patch. Since subversion manages revision number using an integer, adding a column for indicating "which custom patch was applied for this report" to the table will not occupy much space. We will figure out that custom patch needs to be updated via syzbot reports with that column being empty. The custom patch can contain whatever changes which might be useful for debugging. For example, debug printk() for "INFO: task hung in __sb_start_write" case. For another example, context identifier for printk(). Updating custom patches in subversion repository is done manually. But the cost is negligible.
