Re: INFO: rcu detected stall in sys_exit_group

[Tetsuo Handa]

Calling printk() people.

On 2019/09/20 16:50, Dmitry Vyukov wrote:
>>>                                   How it runs on top of an interrupt?
>>
>> It is not running on top of an interrupt.  Its stack was dumped
>> separately.
> 
> I see. Usually the first stack is the traceback of the current stack.
> So I was confused.
> 
>>> And why one cpu tracebacks another one?
>>
>> The usual reason is because neither CPU's quiescent state was reported
>> to the RCU core, so the stall-warning code dumped both stacks.
> 
> But should the other CPU traceback _itself_? Rather than being traced
> back by another CPU?
> E.g. see this report:
> https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/350#L61-L83
> Here the overall problem was detected by C2, but then C1 traces back itself.
> 
> ... however even in that case C0 and C3 are traced by C2:
> https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/350#L84-L149
> I can't understand this...
> This makes understanding what happened harder because it's not easy to
> exclude things on other CPUs.

I think this should be
https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/350#L84-L172
than #L84-L149 .

Is the reason these lines have "[    C2]" is that these lines were flushed (printk_caller_id()
was called) from log_output() from vprintk_store() from vprintk_emit() from vprintk_deferred()
 from printk_deferred() from printk_safe_flush_line() from __printk_safe_flush() from
printk_safe_flush() from printk_safe_flush_on_panic() from panic() ?