lkml.org 
[lkml]   [2021]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] serial: stm32: optimize spin lock usage
On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote:
> Hi Johan, Erwan
>
> It seems still a bit of a problem in the current version, not deadlock
> but access register at the same time.
>
> For driver , we should consider it running under smp, let's think
> about it for this case:
>
> static void stm32_usart_console_write(struct console *co, const char *s,
> unsigned int cnt)
> {
> .....
> local_irq_save(flags);
> if (port->sysrq)
> locked = 0;
> .....
> access register cr1, tdr, isr
> .....
>
> local_irq_restore(flags);
> }
>
> if port->sysrq is 1, stm32_usart_console_write() just disable local
> irq response by local_irq_save(), at the time of access register cr1,
> tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> mpu/mcu do not have multi cores, just assume it has), it still has a
> chance to handle interrupt. Then there is no lock to protect the uart
> register.

Right, the sysrq handling is a bit of a hack.

> changes to below, should be more safe:
>
> .....
> if (port->sysrq || oops_in_progress)
> locked = spin_trylock_irqsave(&port->lock, flags);

Except that the lock debugging code would detect the attempt at
recursive locking here and complain loudly on UP.

If you really want to fix this, we have uart_unlock_and_check_sysrq()
which can be used to defer sysrq processing until the interrupt handler
has released the lock.

> else
> spin_lock_irqsave(&port->lock, flags);
>
> ....
>
> if (locked)
> spin_unlock_irqrestore(&port->lock, flags);

Johan

\
 
 \ /
  Last update: 2021-04-16 10:37    [W:0.156 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site