lkml.org 
[lkml]   [2019]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] tty/sysrq: Convert show_lock to raw_spinlock_t
From
Date
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

\
 
 \ /
  Last update: 2019-03-06 12:09    [W:0.047 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site