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

[Steven Rostedt]

On Mon, 4 Mar 2019 22:25:41 +0000
Julien Grall <Julien.Grall@xxxxxxx> wrote:

> Hello Sebastian,
> 
> 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@xxxxxxx>  
> > 
> > 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.

Also, there's a big discussion going on in LKML right now about
rewriting how the printk buffers work.

-- Steve