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
| ||
|
Date: Tue, 12 Oct 2010 09:40:20 +0100 From: James Hogan <james@...anarts.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Gary Zambrano <zambrano@...adcom.com>, Jiri Pirko <jpirko@...hat.com>, FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>, Hauke Mehrtens <hauke@...ke-m.de>, Larry Finger <Larry.Finger@...inger.net>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH] b44: fix resume, request_irq after hw reset On 12 October 2010 08:27, Andrew Morton <akpm@...ux-foundation.org> wrote: > On Tue, 12 Oct 2010 08:08:05 +0100 James Hogan <james@...anarts.com> wrote: > >> > > @@ -2309,6 +2303,12 @@ static int b44_resume(struct ssb_device *sdev) >> > > >> > > netif_device_attach(bp->dev); >> > > spin_unlock_irq(&bp->lock); >> > > >> > > + rc = request_irq(dev->irq, b44_interrupt, IRQF_SHARED, dev->name, >> dev); >> > > + if (rc) { >> > > + netdev_err(dev, "request_irq failed\n"); >> > > + return rc; >> > > + } >> > > + >> > > >> > > b44_enable_ints(bp); >> > > netif_wake_queue(dev); >> > >> > OK, running the interrupt handler before b44_init_hw() is presumably >> > the problem here. >> > >> > The hardware surely won't be generating interrupts until we've run >> > b44_init_hw() and b44_enable_ints(), so this patch really is only to >> > keep CONFIG_DEBUG_SHIRQ happy. >> >> For me it's mainly to keep CONFIG_DEBUG_SHIRQ happy (Fedora has this switched >> on), but since it's a shared IRQ, there is still a chance it could be >> called before enabling it's own interrupts by a different device on the same >> IRQ. > > ooh, yes, you're right, I forgot about that. It's indeed a bug. > >> It makes sense to me why it's disabling the IRQ now, in case another device >> triggers it when it cannot handle it safely. > > What code are you referring to here? There's no disable_irq() in that area? Sorry, I meant freeing the irq (free_irq() in b44_suspend). Thinking about it this should also go in stable too. Cheers James > >> I also tried calling the >> interrupt directly before the free_irq in the suspend function to check that >> it wasn't being done too late, and it didn't fail, so possibly it is the core >> suspension that makes it start failing until it is brought back up properly. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists