Re: [PATCH] tty/sysrq: Convert show_lock to raw_spinlock_t

[Julien Grall <julien.grall@arm.com>]

Hi Steve,

On 04/03/2019 23:15, Steven Rostedt wrote:
> On Mon, 4 Mar 2019 22:25:41 +0000
> Julien Grall <Julien.Grall@arm.com> wrote:
>> On 04/03/2019 22:01, Sebastian Andrzej Siewior wrote:
>>> On 2019-03-04 17:21:57 [+0000], Julien Grall wrote:
>>>> (CC correctly linux-rt-users)
>>>>
>>>> On 04/03/2019 17:20, Julien Grall wrote:
>>>>> At the moment show_lock is implemented using spin_lock_t and called from
>>>>> an interrupt context on Arm64. The following backtrace was triggered by:
>>>>>
>>>>> 42sh# echo l > /proc/sysrq-trigger
>>>>>
>>>>> [ 4432.073756] sysrq: SysRq : Show backtrace of all active CPUs
>>>>> [ 4432.403422] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:974
>>>>> [ 4432.403424] sysrq: CPU6:
>>>>> [ 4432.403426] in_atomic(): 1, irqs_disabled(): 128, pid: 2410, name: kworker/u16:2
>>>>>
>>>>> [...]
>>>>>
>>>>> [ 4432.403581] Call trace:
>>>>> [ 4432.403584]  dump_backtrace+0x0/0x148
>>>>> [ 4432.403586]  show_stack+0x14/0x20
>>>>> [ 4432.403588]  dump_stack+0x9c/0xd4
>>>>> [ 4432.403592]  ___might_sleep+0x1cc/0x298
>>>>> [ 4432.403595]  rt_spin_lock+0x5c/0x70
>>>>> [ 4432.403596]  showacpu+0x34/0x68
>>>>> [ 4432.403599]  flush_smp_call_function_queue+0xd4/0x278
>>>>> [ 4432.403602]  generic_smp_call_function_single_interrupt+0x10/0x18
>>>>> [ 4432.403605]  handle_IPI+0x26c/0x668
>>>>> [ 4432.403607]  gic_handle_irq+0x9c/0xa0
>>>>> [ 4432.403609]  el1_irq+0xb4/0x13c
>>>>>
>>>>> With RT-patches, spin_lock can now sleep and therefore cannot be used from
>>>>> interrupt context. Use a raw_spin_lock instead to prevent the lock to
>>>>> sleep.
>>>>>
>>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>
>>> I don't have to look at this properly but this looks is wrong.
>>
>> May I ask why does it look wrong? On Arm64, this code is called from an
>> IRQ disabled context (see the check in flush_smp_call_function_queue).
> 
> I'll answer.
>
> It's going to call printk, and depending on consoles and such, it may
> not print anything (a printk without atomic consoles shows nothing).
> 
> That said, perhaps we need to do something like the "safe printk",
> where it only loads it into the log buffers and doesn't do the actual
> prints.
> 
> Hmm, do we do that now? I need to look at the latest printk code in RT.

Thank you for the explanation.

I am not entirely familiar with printk, so I may have overlooked something.

Looking at the printk code (see vprintk_emit), the message will be loaded in the 
log buffer. The log buffer will be printed out by klogd if vprintk_emit were 
called from a context where IRQs or preemption is disabled.

So I think the printk should still happen from atomic context but it will get 
delayed until we are out from the atomic context.

Cheers,

-- 
Julien Grall