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