On Tue, Jul 27, 2010 at 09:28:54PM +0200, Bart Van Assche wrote: > I have two more questions: - Some time ago I observed that the > kernel reported soft lockups because of spin_lock() calls inside a > completion handler. These spinlocks were not locked in any other > context than the completion handler itself. And the lockups > disappeared after having replaced the spin_lock() calls by > spin_lock_irqsave(). Can it be concluded from this observation that > completion handlers are not always invoked from interrupt context ?
I don't know.. It wouldn't surprise me if there were some error paths that called completion handlers outside an IRQ context, but as Roland pointed out the API guarantee is that this never happens in parallel with interrupt called cases. > - The function handle_edge_irq() in kernel/irq/chip.c invokes the > actual interrupt handler while the spinlock desc->lock is not > locked. Does that mean that a completion interrupt can get lost due > to the It holds desc->lock while manipulating the flags, so IRQ_PENDING will be set by CPU 2 and CPU 1 will notice once and re-invoke the handler once it re-locks desc. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
