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

[Julien Grall]

Hi Steve,

On 04/03/2019 23:15, Steven Rostedt wrote:
> On Mon, 4 Mar 2019 22:25:41 +0000
> Julien Grall <Julien.Grall@xxxxxxx> 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@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.

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