lkml.org 
[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: locking problems
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/

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