lkml.org 
[lkml]   [2018]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: what trees/branches to test on syzbot
From
Date
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.

\
 
 \ /
  Last update: 2018-07-05 12:50    [W:0.134 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site