6:35 p.m.
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