Hello.
I think that this patch helps examining reports like
https://syzkaller.appspot.com/text?tag=CrashLog=150eab9140
where there is a TASK_RUNNING thread with a lock held
1 lock held by syz-executor0/18295:
and presumably it is the lock which the hung tasks are waiting for.
On
Hello.
I think that this patch helps examining reports like
https://syzkaller.appspot.com/text?tag=CrashLog=150eab9140
where there is a TASK_RUNNING thread with a lock held
1 lock held by syz-executor0/18295:
and presumably it is the lock which the hung tasks are waiting for.
On
On 2018/09/03 20:44, Tetsuo Handa wrote:
> We are getting reports from syzbot where running task seems to be
> relevant to a hung task problem but NMI backtrace does not print useful
> information [1].
According to my local cache, 69% of hung task reports from syzbot say that
one CPU was running
On 2018/09/03 20:44, Tetsuo Handa wrote:
> We are getting reports from syzbot where running task seems to be
> relevant to a hung task problem but NMI backtrace does not print useful
> information [1].
According to my local cache, 69% of hung task reports from syzbot say that
one CPU was running
We are getting reports from syzbot where running task seems to be
relevant to a hung task problem but NMI backtrace does not print useful
information [1].
Although commit 8cc05c71ba5f7936 ("locking/lockdep: Move sanity check to
inside lockdep_print_held_locks()") says that calling
We are getting reports from syzbot where running task seems to be
relevant to a hung task problem but NMI backtrace does not print useful
information [1].
Although commit 8cc05c71ba5f7936 ("locking/lockdep: Move sanity check to
inside lockdep_print_held_locks()") says that calling
6 matches
Mail list logo
