Re: [PATCH v3] serial: stm32: optimize spin lock usage
From: dillon min
Date: Sat Apr 17 2021 - 09:10:29 EST
Hi Johan,
On Fri, Apr 16, 2021 at 10:10 PM Johan Hovold <johan@xxxxxxxxxx> wrote:
>
> On Fri, Apr 16, 2021 at 06:10:41PM +0800, dillon.minfei@xxxxxxxxx wrote:
> > From: dillon min <dillon.minfei@xxxxxxxxx>
> >
> > This patch aims to fix two potential bug:
> > - no lock to protect uart register in this case
> >
> > stm32_usart_threaded_interrupt()
> > spin_lock(&port->lock);
> > ...
> > stm32_usart_receive_chars()
> > uart_handle_sysrq_char();
> > sysrq_function();
> > printk();
> > stm32_usart_console_write();
> > locked = 0; //since port->sysrq is not zero,
> > no lock to protect forward register
> > access.
> >
> > - if add spin_trylock_irqsave() to protect uart register for sysrq = 1 case,
> > that might got recursive locking under UP.
> > So, use uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq()
> > move sysrq handler position to irq/thread_d handler, just record
> > sysrq_ch in stm32_usart_receive_chars() by uart_prepare_sysrq_char()
> > delay the sysrq process to next interrupt handler.
> >
> > new flow:
> >
> > stm32_usart_threaded_interrupt()/stm32_usart_interrupt()
> > spin_lock_irqsave(&port->lock);
> > ...
> > uart_unlock_and_check_sysrq();
> > spin_unlock_irqrestore();
> > handle_sysrq(sysrq_ch);
> > stm32_usart_threaded_interrupt()//stm32_usart_interrupt() return
> >
> > Cc: Johan Hovold <johan@xxxxxxxxxx>
> > Cc: Alexandre Torgue <alexandre.torgue@xxxxxxxxxxx>
> > Cc: Maxime Coquelin <mcoquelin.stm32@xxxxxxxxx>
> > Cc: Gerald Baeza <gerald.baeza@xxxxxxxxxxx>
> > Cc: Erwan Le Ray <erwan.leray@xxxxxxxxxxx>
> > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > Signed-off-by: dillon min <dillon.minfei@xxxxxxxxx>
> > ---
> > v3: add uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq() to move
> > sysrq handler inside interrupt routinei to avoid recursive locking,
> > according to Johan Hovold suggestion, thanks.
> >
> > drivers/tty/serial/stm32-usart.c | 24 +++++++++++-------------
> > 1 file changed, 11 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > index b3675cf25a69..981f50ec784e 100644
> > --- a/drivers/tty/serial/stm32-usart.c
> > +++ b/drivers/tty/serial/stm32-usart.c
> > @@ -271,7 +271,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > }
> > }
> >
> > - if (uart_handle_sysrq_char(port, c))
> > + if (uart_prepare_sysrq_char(port, c))
> > continue;
> > uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> > }
> > @@ -457,9 +457,10 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
> > struct uart_port *port = ptr;
> > struct stm32_port *stm32_port = to_stm32_port(port);
> > const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > + unsigned long flags;
> > u32 sr;
> >
> > - spin_lock(&port->lock);
> > + spin_lock_irqsave(&port->lock, flags);
> >
> > sr = readl_relaxed(port->membase + ofs->isr);
> >
> > @@ -477,7 +478,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
> > if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch))
> > stm32_usart_transmit_chars(port);
> >
> > - spin_unlock(&port->lock);
> > + uart_unlock_and_check_sysrq(port, flags);
> >
> > if (stm32_port->rx_ch)
> > return IRQ_WAKE_THREAD;
> > @@ -489,13 +490,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
> > {
> > struct uart_port *port = ptr;
> > struct stm32_port *stm32_port = to_stm32_port(port);
> > + unsigned long flags;
> >
> > - spin_lock(&port->lock);
> > + spin_lock_irqsave(&port->lock, flags);
>
> This essentially turns the threaded handler into a non-threaded one,
> which is a bad idea.
This change is only to adapt for uart_unlock_and_check_sysrq() need flags.
Found your patch has removed this parameter from
uart_unlock_and_check_sysrq(), so this changes should be removed.
>
> > if (stm32_port->rx_ch)
> > stm32_usart_receive_chars(port, true);
> >
> > - spin_unlock(&port->lock);
> > + uart_unlock_and_check_sysrq(port, flags);
> >
> > return IRQ_HANDLED;
> > }
>
> You also didn't base this patch on tty-next, which has a number of
> updates to this driver. Before noting that myself, I had fixed a couple
> of deadlocks in this driver which turned out to have been incidentally
> fixed by an unrelated path in -next.
Yes, my submission is based on linux-5.12. based on the component's
next branch is a good idea , to avoid conflict. thanks.
>
> I'll be posting a series that should fix up all of this.
Thanks
>
> Johan