linux-kernel - Re: [PATCH] serial: stm32: optimize spin lock usage

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>
Date:   Mon, 12 Apr 2021 16:54:54 +0800
From:   dillon min <dillon.minfei@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     jirislaby@...nel.org, Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...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>
Subject: Re: [PATCH] serial: stm32: optimize spin lock usage

Hi Greg,

On Mon, Apr 12, 2021 at 4:25 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
> > Hi Greg，
> >
> > Thanks for the quick response, please ignore the last private mail.
> >
> > On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei@...il.com wrote:
> > > > From: dillon min <dillon.minfei@...il.com>
> > > >
> > > > To avoid potential deadlock in spin_lock usage, change to use
> > > > spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
> > > > spin_lock(), spin_unlock() under handler context.
> > > >
> > > > remove unused local_irq_save/restore call.
> > > >
> > > > Signed-off-by: dillon min <dillon.minfei@...il.com>
> > > > ---
> > > > Was verified on stm32f469-disco board. need more test on stm32mp platform.
> > > >
> > > >  drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
> > > >  1 file changed, 17 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > > > index b3675cf25a69..c4c859b34367 100644
> > > > --- a/drivers/tty/serial/stm32-usart.c
> > > > +++ b/drivers/tty/serial/stm32-usart.c
> > > > @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > > >       struct tty_port *tport = &port->state->port;
> > > >       struct stm32_port *stm32_port = to_stm32_port(port);
> > > >       const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > > > -     unsigned long c;
> > > > +     unsigned long c, flags;
> > > >       u32 sr;
> > > >       char flag;
> > > >
> > > > @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > > >               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> > > >       }
> > > >
> > > > -     spin_unlock(&port->lock);
> > > > +     if (threaded)
> > > > +             spin_unlock_irqrestore(&port->lock, flags);
> > > > +     else
> > > > +             spin_unlock(&port->lock);
> > >
> > > You shouldn't have to check for this, see the other patches on the list
> > > recently that fixed this up to not be an issue for irq handlers.
> > Can you help to give more hints, or the commit id of the patch which
> > fixed this. thanks.
> >
> > I'm still confused with this.
> >
> > The stm32_usart_threaded_interrupt() is a kthread context, once
> > port->lock holds by this function, another serial interrupts raised,
> > such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
> > there will be a deadlock. isn't it?
> >
> >  So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?
>
> Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
> handlers") for when threaded irq handlers have irqs disabled, isn't that
> the case you are trying to "protect" from here?
>
> Why is the "threaded" flag used at all?  The driver should not care.
>
> Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
> threading") in linux-next for an example of how this was fixed up in a
> serial driver.
>
> does that help?
>
Yes, it's really helpful. and 81e2073c175b should be highlighted in a doc.
In my past knowledge, we should care about hard irq & thread_fn lock conflict.
This patch has totally avoided patching code in the separate driver side.
thanks.

I will just keep the changes in stm32_usart_console_write(), remove
these code in
thread_fn. update version 2 for you.

thanks.

Dillon,
> thanks,
>
> greg k-h