Jun Sun wrote:
>
> BTW, I really think interrupt handlers acquiring the same locks which
> can be acquired by processes is a *BIG* problem in Linux. We should fix
> this problem. Unfortunately I am not familiar with Linux kernel well
> enough to offer a solution.
Why do you think this? Any specific examples in mind?
This should be relatively easy to test for.
- Add a field to spinlock_t (locked_in_isr)
- Ditto for rwlock_t (bit more complex...)
- If a spinlock is grabbed in an ISR, note this within its locked_in_isr
field. (Probably need to futz with do_IRQ a bit to know when we're "In
an ISR").
- If a spinlock is grabbed outside an ISR AND not with a *_irq()
function AND its locked_in_isr field is set then BUG().
The interrupt latency stuff I did is halfway there. It'd be a matter of
hijacking the spinlock() functions as well as the cli/sti stuff.
Problems I see are:
1: Coverage: I don't think anyone in the world owns more than 10% of the
hardware (and hence s/w) which the kernel supports. You'd need lots of
testers running this and that won't happen.
2: It won't 100% detect abuses with dynamically allocated locks (such as
the one in sk_buff_head).
3: It won't catch cross-interrupt deadlocks:
spinlock_t some_lock;
Sound ISR Ethernet ISR
========= ============
Gee, I'm in a ISR. I
can do this:
spin_lock(some_lock)
[ Packet arrives ]
Gee, I'm in an ISR.
I can do this:
spin_lock(some_lock)
One would have to make the locked_in_isr field a bitfield to detect
this. Each bit corresponding to a particular ISR.
Have a think, please tell me if I've missed something. I can take a
look a this in 2-3 weeks time.
The coverage problem greatly devalues efforts like this, which is a
great pity (permanent debug code...)
-- -akpm-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST