linux-kernel - RE: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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