linux-kernel - Re: irq 16: nobody cared

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.LFD.2.02.1304221432570.21884@ionos>
Date:	Mon, 22 Apr 2013 14:56:08 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Takashi Iwai <tiwai@...e.de>
cc:	Borislav Petkov <bp@...en8.de>, paulmck@...ux.vnet.ibm.com,
	x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: irq 16: nobody cared

On Mon, 22 Apr 2013, Takashi Iwai wrote:
> At Mon, 22 Apr 2013 11:13:10 +0200,
> Borislav Petkov wrote:
> > 
> > On Mon, Apr 22, 2013 at 10:32:17AM +0200, Takashi Iwai wrote:
> > > Hm, if it's really due to a stray irq, just adding the missing
> > > synchronize_irq() like below would help?
> > > 
> > > 
> > > Takashi
> > > 
> > > ---
> > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > > index 7b213d5..262dbf1 100644
> > > --- a/sound/pci/hda/hda_intel.c
> > > +++ b/sound/pci/hda/hda_intel.c
> > > @@ -2682,6 +2682,8 @@ static void azx_stop_chip(struct azx *chip)
> > >  	/* disable interrupts */
> > >  	azx_int_disable(chip);
> > >  	azx_int_clear(chip);
> > > +	if (chip->irq >= 0)
> > > +		synchronize_irq(chip->irq);
> > 
> > Nope, it doesn't help - I see the same splat.
> 
> Thanks.  Then I have no idea what's missing in the current
> azx_suspend() and azx_resume() codes.

I asked Boris to add a disable_irq() on top of the azx_suspend()
function and that does not help either, but it tells us that the
interrupt storm arrives _BEFORE_ azx_suspend() is invoked.

So some other device shuts down and causes that. The obvious question
is whether this interrupt line is shared with something else.

Boris, can you please provide the irq16 line of /proc/interrupts
before you invoke suspend? 

If it's shared we know which driver is shutdown before hda_intel and
perhaps leaves its device in a weird state.

If it's not shared, it still might be shared behind the scene. The
other device uses MSI(X) and when shutdown MSI is disabled so the
default IRQ route which points to IRQ16 would be active again.

I assume, that the RCU stuff just causes enough timing difference to
uncover the underlying issue.

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/