lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL9mu0Kxny5JOGDk67ByMCVAJFOCF44rEOjbt68VxHz_2gZHrg@mail.gmail.com>
Date:   Sat, 17 Apr 2021 21:07:55 +0800
From:   dillon min <dillon.minfei@...il.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...s.st.com>,
        kernel test robot <lkp@...el.com>,
        Gerald Baeza <gerald.baeza@...s.st.com>,
        Erwan LE-RAY - foss <erwan.leray@...s.st.com>,
        linux-serial@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kbuild-all@...ts.01.org, clang-built-linux@...glegroups.com
Subject: Re: [PATCH v3] serial: stm32: optimize spin lock usage

Hi Johan,

On Fri, Apr 16, 2021 at 10:10 PM Johan Hovold <johan@...nel.org> wrote:
>
> On Fri, Apr 16, 2021 at 06:10:41PM +0800, dillon.minfei@...il.com wrote:
> > From: dillon min <dillon.minfei@...il.com>
> >
> > 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@...nel.org>
> > Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32@...il.com>
> > Cc: Gerald Baeza <gerald.baeza@...s.st.com>
> > Cc: Erwan Le Ray <erwan.leray@...s.st.com>
> > Reported-by: kernel test robot <lkp@...el.com>
> > Signed-off-by: dillon min <dillon.minfei@...il.com>
> > ---
> > 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ