>
> This suggests a locking issue. Is there any place in the kernel
> where we take a write lock on tasklist_lock and do a lock_kernel()
> afterwards?
>
> Alternatively, the mm->lock, kernel_lock and/or tasklist_lock could
> be in play all three... Could the changes to ptrace.c be involved
> here?
>
I really need to learn the locking rules for the kernel. As far as
I can see, lock_kernel is a spinning monitor, so any intr code should
be able to grab lock_kernel. Hence, code that is bracketed with a
read_lock(tasklist_lock) .... read_unlock(tasklist_lock) can take an
intr and be trying to get lock_kernel.
Coming to your question, the above does not seem to be the case
for write lock on tasklist_lock, since the irq level is raised.
[kanoj@entity linux]$ gid tasklist_lock | grep -v unlock | grep write | grep -v ar
ch
include/linux/sched.h:844: write_lock_irq(&tasklist_lock);
kernel/exit.c:365: write_lock_irq(&tasklist_lock);
kernel/exit.c:394: write_lock_irq(&tasklist_lock);
kernel/exit.c:515: write_lock_irq(&tasklist_lock);
kernel/fork.c:741: write_lock_irq(&tasklist_lock);
And I don't _think_ that any of this code takes the kernel_lock either
in the straightline execution path.
Kanoj
-
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 : Sun Apr 30 2000 - 21:00:13 EST