Messages in this thread | | | Subject | Re: [PATCH] tty/sysrq: Convert show_lock to raw_spinlock_t | From | Julien Grall <> | Date | Wed, 6 Mar 2019 11:08:52 +0000 |
| |
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
| |