[lkml]   [2003]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[RFC+PATCH] calling request_irq() with lock held (+sungem fix)
Hrm.. old problem: request_irq() called with a lock held.

This is unclear wether this should be safe or not, I now IDE used to
do that, but the current implementation of request_irq() on most archs
is definitely not safe to be called in a non-sleeping context.

i386 was sort-fixed by using GFP_ATOMIC in the kmalloc() done inside
request_irq() itself, but what about all of the proc related stuff
that gets done when setup_irq() calls register_irq_proc() ? So the
_fact_ is that the current implementations in archs, including i386,
are unsafe to call from "atomic" context.

David: this patch fixes sungem for that.


diff -urN linux-2.5/drivers/net/sungem.c linuxppc-2.5-benh/drivers/net/sungem.c
--- linux-2.5/drivers/net/sungem.c 2003-07-29 08:50:59.000000000 -0400
+++ linuxppc-2.5-benh/drivers/net/sungem.c 2003-07-30 13:25:32.000000000 -0400
@@ -2101,17 +2101,14 @@
gp->hw_running = 1;

- spin_lock_irq(&gp->lock);
/* We can now request the interrupt as we know it's masked
* on the controller
if (request_irq(gp->pdev->irq, gem_interrupt,
SA_SHIRQ, dev->name, (void *)dev)) {
- spin_unlock_irq(&gp->lock);
printk(KERN_ERR "%s: failed to request irq !\n", gp->dev->name);

+ spin_lock_irq(&gp->lock);
if (!hw_was_up && gp->pdev->vendor == PCI_VENDOR_ID_APPLE)
@@ -2120,10 +2117,13 @@
gp->pm_timer.expires = jiffies + 10*HZ;
+ spin_unlock_irq(&gp->lock);

return -EAGAIN;

+ spin_lock_irq(&gp->lock);
/* Allocate & setup ring buffers */

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.041 / U:29.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site