> -----Original Message----- > From: Finn Thain [mailto:fthain@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, February 11, 2021 10:07 AM > To: Song Bao Hua (Barry Song) <song.bao.hua@xxxxxxxxxxxxx> > Cc: tanxiaofei <tanxiaofei@xxxxxxxxxx>; jejb@xxxxxxxxxxxxx; > martin.petersen@xxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; linuxarm@xxxxxxxxxxxxx; > linux-m68k@xxxxxxxxxxxxxxx > 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
