[ofa-general] Re: 2.6.30.1: possible irq lock inversion dependency detected

[Roland Dreier]

 > Even if it is really unlikely that this lock cycle would cause a
 > deadlock, it would be great if this lock cycle could be removed. I'm
 > not the only developer of kernel modules who runs tests with lockdep
 > enabled, and it is unpractical to analyze long logfiles full of known
 > lock cycles to find a single lock cycle caused by newly added or
 > recently modified code.

I agree that we should fix all lockdep issues -- the impact of them is
even worse than you realize, because once a single cycle is detected,
lockdep must turn itself off until a reboot, because of course you can't
detect new cycles in a graph that already has a cycle.

 > One possible approach when having to queue events from interrupt
 > context is to queue these events in a fixed size queue that has been
 > allocated outside interrupt context, and make it possible for the
 > event consumer to detect the queue overflow condition. When a queue
 > overflow happens it is the responsibility of the event consumer to
 > query the state of the event producer. This is a more complex approach
 > than callback functions but has the advantage that there never can be
 > a lock cycle involving locks of both the event producer and the event
 > consumer.

I think in most cases dealing with queue overflow is going to lead to
way more bugs than callbacks in interrupt context.  Of course, when
passing events on to userspace, we don't have the luxury of being able
to call userspace in interrupt context, so we have to look for the next
best thing.  But within the kernel we can take the simpler more robust
approach.

 - R.