-----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
