[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9611728-3e7-3954-cfee-f3d3cf45df6@telegraphics.com.au>
Date: Thu, 11 Feb 2021 08:06:56 +1100 (AEDT)
From: Finn Thain <fthain@...egraphics.com.au>
To: "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
cc: tanxiaofei <tanxiaofei@...wei.com>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxarm@...neuler.org" <linuxarm@...neuler.org>,
"linux-m68k@...r.kernel.org" <linux-m68k@...r.kernel.org>
Subject: RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization
for SCSI drivers
On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
> >
> > > > > sonic_interrupt() uses an irq lock within an interrupt handler
> > > > > to avoid issues relating to this. This kind of locking may be
> > > > > needed in the drivers you are trying to patch. Or it might not.
> > > > > Apparently, no-one has looked.
> > >
> > > Is the comment in sonic_interrupt() outdated according to this:
> > > m68k: irq: Remove IRQF_DISABLED
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77a4279
> > > http://lkml.iu.edu/hypermail/linux/kernel/1109.2/01687.html
> > >
> >
> > The removal of IRQF_DISABLED isn't relevant to this driver. Commit
> > 77a42796786c ("m68k: Remove deprecated IRQF_DISABLED") did not disable
> > interrupts, it just removed some code to enable them.
> >
> > The code and comments in sonic_interrupt() are correct. You can
> > confirm this for yourself quite easily using QEMU and a
> > cross-compiler.
> >
> > > and this: genirq: Warn when handler enables interrupts
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b738a50a
> > >
> > > wouldn't genirq report a warning on m68k?
> > >
> >
> > There is no warning from m68k builds. That's because
> > arch_irqs_disabled() returns true when the IPL is non-zero.
>
>
> So for m68k, the case is
> arch_irqs_disabled() is true, but interrupts can still come?
>
> Then it seems it is very confusing. If prioritized interrupts can still
> come while arch_irqs_disabled() is true,
Yes, on m68k CPUs, an IRQ having a priority level higher than the present
priority mask will get serviced.
Non-Maskable Interrupt (NMI) is not subject to this rule and gets serviced
regardless.
> how could spin_lock_irqsave() block the prioritized interrupts?
It raises the the mask level to 7. Again, please see
arch/m68k/include/asm/irqflags.h
> Isn't arch_irqs_disabled() a status reflection of irq disable API?
>
Why not?
Are all interrupts (including NMI) masked whenever arch_irqs_disabled()
returns true on your platforms?
> Thanks
> Barry
>
>
Powered by blists - more mailing lists