Re: Re: INFO: task hung in should_fail

[syzbot]

> The trace contains following lines.

> [ 247.183847] INFO: task kworker/0:3:7985 blocked for more than 120
> seconds.
> [ 247.217677] kworker/0:3 D
> [ 247.234816] Workqueue: events cgwb_release_workfn
> [ 247.345883] schedule+0xf5/0x430
> [ 247.445577] bit_wait+0x18/0x90
> [ 247.457661] __wait_on_bit+0x88/0x130
> [ 247.469579] out_of_line_wait_on_bit+0x204/0x3a0
> [ 247.511761] wb_shutdown+0x335/0x430
> [ 247.544066] cgwb_release_workfn+0x8b/0x622

> This will be a dup of "INFO: task hung in wb_shutdown (2)".

> #syz dup: INFO: task hung in wb_shutdown (2)

Dup bug is already upstreamed.

[Tetsuo Handa]

[syzbot]

Dup bug is already upstreamed.

> --
> 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-bug...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/201804141958.GAD86933.SQJMLOVFtFHOFO%40I-love.SAKURA.ne.jp.
> For more options, visit https://groups.google.com/d/optout.

[Dmitry Vyukov]

On Sat, Apr 14, 2018 at 12:58 PM, syzbot
<syzbot+f4b1cb...@syzkaller.appspotmail.com> wrote:
>> The trace contains following lines.
>
>> [ 247.183847] INFO: task kworker/0:3:7985 blocked for more than 120
>> seconds.
>> [ 247.217677] kworker/0:3 D
>> [ 247.234816] Workqueue: events cgwb_release_workfn
>> [ 247.345883] schedule+0xf5/0x430
>> [ 247.445577] bit_wait+0x18/0x90
>> [ 247.457661] __wait_on_bit+0x88/0x130
>> [ 247.469579] out_of_line_wait_on_bit+0x204/0x3a0
>> [ 247.511761] wb_shutdown+0x335/0x430
>> [ 247.544066] cgwb_release_workfn+0x8b/0x622
>
>
>> This will be a dup of "INFO: task hung in wb_shutdown (2)".
>
>
>> #syz dup: INFO: task hung in wb_shutdown (2)
>
>
> Dup bug is already upstreamed.

There is somewhat complicated story with cross-reporting dups.
For example, if a bug in "moderation" is marked as dup of a bug in
"upstream", and then later the moderation bug is "upstreamed" (sent to
kernel mailing lists). What should happen with "dup" status and how
should it be explained in the report (e.g. "syzbot hit bug X but we
already know that this is a dup of Y")?
How should dups from upstream to moderation be handled? Or prohibited at all?
This can also hide important information from developers. Consider
that upstream bug does not have a repro, but the moderation bug later
gets a repro. Nobody knows about it.
And there were some other corner cases as far as I remember. So I
decided to go with a simpler option initially -- prohibit them
entirely.
I've filed https://github.com/google/syzkaller/issues/569 but not all
aspects of cross-reporting dup handling are still clear for me.

For now the intended way of handling this is:
1. upstream this bug (with "#syz upstream" commend)
2. when it appears on kernel lists, we can dup as necessary

Or, bugs in moderation can be closed right there with syz fix/invalid.

However, this particular report looks corrupted due to intermixed
kernel output (the hang is definitely not in should_fail). We try to
detect and filter out such reports, but it's an infinite race.
I've fixed this particular case in
https://github.com/google/syzkaller/commit/61155cf882e58826d0efa2c7d2e2796080c93923
so:

#syz invalid