linux-kernel - Re: [PATCH] genirq: Fix bad IRQ

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: <alpine.DEB.2.11.1509180955290.3951@nanos>
Date:	Fri, 18 Sep 2015 11:04:23 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Kohji Okuno <okuno.kohji@...panasonic.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Marc Zyngier <marc.zyngier@....com>
Subject: Re: [PATCH] genirq: Fix bad IRQ_ONSHOT in forced IRQ setting

On Fri, 18 Sep 2015, Kohji Okuno wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
> Date: Thu, 17 Sep 2015 23:10:02 +0200
> > On Thu, 17 Sep 2015, Kohji Okuno wrote:
> >>
> >> When 1st sdio IRQ is happend, sdhci_irq() returns IRQ_WAKE_THREAD.
> >> After this, sdhci_irq() is not called in case of threadirqs.
> > 
> > What kind of system is that?
> > 
> > Can you provide the output of /proc/interrupts please?
> > 
> > I think your patch is fine. I just want to understand why we don't see
> > any more interrupts.
> > 
> > Thanks,
> > 
> > 	tglx
> 
> Hi tglx,
> 
> My system is arm, and I connect SDIO WiFi card.
> In fact, I use kernel 3.18.11 base. But, I think sources concerned
> with this are same. 
> 
> This is my "/proc/interrupts".
> 
>            CPU0       CPU1       CPU2       CPU3
>  46:      20672          0          0          0       GIC  46  mmc1
> 
> In drivers/irqchip/irq-gic.c:gic_set_type(), irq46 is set as
> IRQ_TYPE_LEVEL_HIGH.

That's weird. The flow is:

interrupt()
  mask()
  ret = primary_handler()
  if (ret == WAKE_THREAD)
    wake_thread()
  else
    unmask()

thread_handler()
  ....
  unmask()

So if an interrupt is triggered on the device while the interrupt is
masked it should be raised again immediately when the unmask happens
because its level type.

I'm wondering why that doesn't work.

Thanks,

	tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/