linux-kernel - RE: 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]

Message-ID: <c7fdb63e-e84-c685-35f4-6b6f663cd867@telegraphics.com.au>
Date:   Fri, 12 Feb 2021 10:57:17 +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: Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI
 drivers


On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:

> 
> Actually in m68k, I also saw its IRQ entry disabled interrupts by
> ' move	#0x2700,%sr		/* disable intrs */'
> 
> arch/m68k/include/asm/entry.h:
> 
> .macro SAVE_ALL_SYS
> 	move	#0x2700,%sr		/* disable intrs */
> 	btst	#5,%sp@(2)		/* from user? */
> 	bnes	6f			/* no, skip */
> 	movel	%sp,sw_usp		/* save user sp */
> ...
> 
> .macro SAVE_ALL_INT
> 	SAVE_ALL_SYS
> 	moveq	#-1,%d0			/* not system call entry */
> 	movel	%d0,%sp@(PT_OFF_ORIG_D0)
> .endm
> 
> arch/m68k/kernel/entry.S:
> 
> /* This is the main interrupt handler for autovector interrupts */
> 
> ENTRY(auto_inthandler)
> 	SAVE_ALL_INT
> 	GET_CURRENT(%d0)
> 					|  put exception # in d0
> 	bfextu	%sp@(PT_OFF_FORMATVEC){#4,#10},%d0
> 	subw	#VEC_SPUR,%d0
> 
> 	movel	%sp,%sp@-
> 	movel	%d0,%sp@-		|  put vector # on stack
> auto_irqhandler_fixup = . + 2
> 	jsr	do_IRQ			|  process the IRQ
> 	addql	#8,%sp			|  pop parameters off stack
> 	jra	ret_from_exception
> 
> So my question is that " move	#0x2700,%sr" is actually disabling
> all interrupts? And is m68k actually running irq handlers
> with interrupts disabled?
> 

When sonic_interrupt() executes, the IPL is 2 or 3 (since either IRQ may 
be involved). That is, SR & 0x700 is 0x200 or 0x300. The level 3 interrupt 
may interrupt execution of the level 2 handler so an irq lock is used to 
avoid re-entrance.

This patch,

diff --git a/drivers/net/ethernet/natsemi/sonic.c b/drivers/net/ethernet/natsemi/sonic.c
index d17d1b4f2585..041354647bad 100644
--- a/drivers/net/ethernet/natsemi/sonic.c
+++ b/drivers/net/ethernet/natsemi/sonic.c
@@ -355,6 +355,8 @@ static irqreturn_t sonic_interrupt(int irq, void *dev_id)
         */
        spin_lock_irqsave(&lp->lock, flags);
 
+       printk_once(KERN_INFO "%s: %08lx\n", __func__, flags);
+
        status = SONIC_READ(SONIC_ISR) & SONIC_IMR_DEFAULT;
        if (!status) {
                spin_unlock_irqrestore(&lp->lock, flags);

produces this output,

[    3.800000] sonic_interrupt: 00002300

I ran that code in QEMU, but experience shows that Apple hardware works 
exactly the same. Please do confirm this for yourself, if you still think 
the code and comments in sonic_interrupt are wrong.

> Best Regards
> Barry
>