Messages in this thread | | | From | "Song Bao Hua (Barry Song)" <> | Subject | RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers | Date | Wed, 10 Feb 2021 21:28:53 +0000 |
| |
> -----Original Message----- > From: Finn Thain [mailto:fthain@telegraphics.com.au] > Sent: Thursday, February 11, 2021 10:07 AM > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com> > Cc: tanxiaofei <tanxiaofei@huawei.com>; jejb@linux.ibm.com; > martin.petersen@oracle.com; linux-scsi@vger.kernel.org; > linux-kernel@vger.kernel.org; linuxarm@openeuler.org; > linux-m68k@vger.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
Hi Finn, Thanks for your explanation again.
TBH, that is why m68k is so confusing. irqs_disabled() on m68k should just reflect the status of all interrupts have been disabled except NMI.
irqs_disabled() should be consistent with the calling of APIs such as local_irq_disable, local_irq_save, spin_lock_irqsave etc.
> > > Isn't arch_irqs_disabled() a status reflection of irq disable API? > > > > Why not?
If so, arch_irqs_disabled() should mean all interrupts have been masked except NMI as NMI is unmaskable.
> > Are all interrupts (including NMI) masked whenever arch_irqs_disabled() > returns true on your platforms?
On my platform, once irqs_disabled() is true, all interrupts are masked except NMI. NMI just ignore spin_lock_irqsave or local_irq_disable.
On ARM64, we also have high-priority interrupts, but they are running as PESUDO_NMI: https://lwn.net/Articles/755906/
On m68k, it seems you mean: irq_disabled() is true, but high-priority interrupts can still come; local_irq_disable() can disable high-priority interrupts, and at that time, irq_disabled() is also true.
TBH, this is wrong and confusing on m68k.
> > > Thanks > > Barry > >
Thanks Barry
| |