Re: [patch] 2.3.99-pre6-3 VM fixed

From: Kanoj Sarcar (
Date: Thu Apr 27 2000 - 15:20:24 EST

> 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
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST