On Fri, Mar 19, 2021 at 10:09 AM Johan Hovold <jo...@kernel.org> wrote: > > On Fri, Mar 19, 2021 at 06:36:39AM +0000, Song Bao Hua (Barry Song) wrote: > > > > > > > -----Original Message----- > > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > > > Sent: Tuesday, March 16, 2021 10:41 PM > > > To: Johan Hovold <jo...@kernel.org>; Finn Thain > > > <fth...@telegraphics.com.au>; > > > Song Bao Hua (Barry Song) <song.bao....@hisilicon.com> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlow...@canonical.com>; Greg > > > Kroah-Hartman <gre...@linuxfoundation.org>; Jiri Slaby > > > <jirisl...@kernel.org>; > > > linux-arm Mailing List <linux-arm-ker...@lists.infradead.org>; Linux > > > Samsung > > > SOC <linux-samsung-...@vger.kernel.org>; open list:SERIAL DRIVERS > > > <linux-ser...@vger.kernel.org>; Linux Kernel Mailing List > > > <linux-kernel@vger.kernel.org>; Hector Martin <mar...@marcan.st>; Arnd > > > Bergmann <a...@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 <jo...@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. > > Forced threaded interrupts have so far run with interrupts enabled and > spin_lock_irqsave() would suffice on non-RT. This is about to change > though so that drivers don't need to worry about "threadirqs": > > https://lore.kernel.org/r/20210317143859.513307...@linutronix.de > > > 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. > > No, no. RT handles this by deferring console writes apparently. > > > I think it is almost always wrong to call spin_lock_irqsave in hardirq. > > Again, no. It's even been a requirement due to "threadirqs" in some > cases (e.g. hrtimers) up until now (or rather until the above patch is > in mainline).
By the way, a good question Imre (Cc'ed) and I have discussed is the in-kernel documentation, i.e. https://www.kernel.org/doc/html/latest/kernel-hacking/locking.html. Should it be adjusted to reality? -- With Best Regards, Andy Shevchenko
