On Thu, 2002-10-17 at 23:39, Andrew Morton wrote:
> request_irq() was changed to use GFP_ATOMIC, so it's "fixed".
>
> But only for i386.
>
> request_irq() inside spinlock is a *very* common bug. Moreso
> as people move cli()-using code across to use spinlocks.
>
> And we've just lost our ability to detect this bug.
>
> request_irq() needs to take the allocation mode as an argument.
> Should always have. Sigh. I'll fix it up sometime.
Many of the people who use request_irq out of spinlocks are actually the
buggy ones, especially in the PCI world. Im not sure passing the
argument is the real fix. I'd like to be able to write code that was
more of the form
irqptr = allocate_irq(irqnum, flags, handler, &err);
install_irq(irqptr);
That would clean up vast amounts of locking, if I can allocate, check I
can obtain and handle all the setup -before- I turn the IRQ one.
enable/disable_irq doesnt really cut it for granularity and has the same
can't sleep issue
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:52 EST