From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
Johan Hovold <johan@kernel.org>,
Finn Thain <fthain@telegraphics.com.au>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hector Martin <marcan@marcan.st>,
"Arnd Bergmann" <arnd@kernel.org>
Subject: RE: [PATCH] tty: serial: samsung_tty: remove spinlock flags in interrupt handlers
Date: Fri, 19 Mar 2021 06:36:39 +0000 [thread overview]
Message-ID: <4771468d968a44789518bc547acf5f93@hisilicon.com> (raw)
In-Reply-To: <CAHp75VfcbC63t_eZeBOA0NY28BtGBD0YyLR6nSNuKAnKhXTSzA@mail.gmail.com>
> -----Original Message-----
> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Sent: Tuesday, March 16, 2021 10:41 PM
> To: Johan Hovold <johan@kernel.org>; Finn Thain <fthain@telegraphics.com.au>;
> Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Greg
> Kroah-Hartman <gregkh@linuxfoundation.org>; Jiri Slaby <jirislaby@kernel.org>;
> linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>; Linux Samsung
> SOC <linux-samsung-soc@vger.kernel.org>; open list:SERIAL DRIVERS
> <linux-serial@vger.kernel.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Hector Martin <marcan@marcan.st>; Arnd
> Bergmann <arnd@kernel.org>
> Subject: Re: [PATCH] tty: serial: samsung_tty: remove spinlock flags in
> interrupt handlers
>
> On Tue, Mar 16, 2021 at 11:02 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Mon, Mar 15, 2021 at 07:12:12PM +0100, Krzysztof Kozlowski wrote:
> > > Since interrupt handler is called with disabled local interrupts, there
> > > is no need to use the spinlock primitives disabling interrupts as well.
> >
> > This isn't generally true due to "threadirqs" and that can lead to
> > deadlocks if the console code is called from hard irq context.
> >
> > Now, this is *not* the case for this particular driver since it doesn't
> > even bother to take the port lock in console_write(). That should
> > probably be fixed instead.
> >
> > See https://lore.kernel.org/r/X7kviiRwuxvPxC8O@localhost.
>
> Finn, Barry, something to check I think?
My understanding is that spin_lock_irqsave can't protect the context
the console_write() is called in hardirq for threaded_irq case mainly
for preempt-rt scenarios as spin_lock_irqsave doesn't disable irq in
that case at all.
See:
https://www.kernel.org/doc/html/latest/locking/locktypes.html
spinlock_t and PREEMPT_RT
On a PREEMPT_RT kernel spinlock_t is mapped to a separate implementation
based on rt_mutex which changes the semantics:
Preemption is not disabled.
The hard interrupt related suffixes for spin_lock / spin_unlock operations
(_irq, _irqsave / _irqrestore) do not affect the CPU’s interrupt disabled
state.
So if console_write() can interrupt our code in hardirq, we should
move to raw_spin_lock_irqsave for this driver.
I think it is almost always wrong to call spin_lock_irqsave in hardirq.
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks
Barry
next prev parent reply other threads:[~2021-03-19 6:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 18:12 Krzysztof Kozlowski
2021-03-15 18:16 ` Andy Shevchenko
2021-03-16 9:02 ` Johan Hovold
2021-03-16 9:40 ` Andy Shevchenko
2021-03-19 6:36 ` Song Bao Hua (Barry Song) [this message]
2021-03-19 8:10 ` Johan Hovold
2021-03-19 10:09 ` Andy Shevchenko
2021-03-19 15:05 ` Johan Hovold
2021-03-16 9:47 ` Krzysztof Kozlowski
2021-03-16 9:56 ` Johan Hovold
2021-03-16 10:11 ` Krzysztof Kozlowski
2021-03-16 11:25 ` Johan Hovold
2021-03-22 11:23 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4771468d968a44789518bc547acf5f93@hisilicon.com \
--to=song.bao.hua@hisilicon.com \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@kernel.org \
--cc=fthain@telegraphics.com.au \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=marcan@marcan.st \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®