Messages in this thread | | | Date | Thu, 28 Jan 1999 23:04:42 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] fixed both processes in D state and the /proc/ oopses [Re: [patch] Fixed the race that was oopsing Linux-2.2.0] |
| |
On Thu, 28 Jan 1999, Linus Torvalds wrote:
> Incorrect, see my previous email. It may not be strictly necessary right > now due to us probably holding the kernel lock everywhere, but it is > conceptually necessary, and it is _not_ an argument for a spinlock.
If you remove the kernel lock around do_exit() you _need_ my mm_lock spinlock. You need it to make atomic the decreasing of mm->count and current->mm = &init_mm. If the two instructions are not atomic you have _no_ way to know if you can mmget() at any time the mm of a process.
I repeat in another way (just trying to avoid English mistakes): decreasing mm->count has to go in sync with updating current->mm, otherwise you don't know if you can access the mm of a process (and so also touching mm->count) because the mm of such process could be just been deallocated (the process could be a zombie).
As far I can see the mm->count will _never_ have 1 reason to be atomic_t even removing the function lock_kernel() from /usr/src/linux/include/asm/smplock.h .
Using an int for mm->count (isntead of atomic_t) is far from be something of magic. Doing that change it means that I don't expect work by magic, but I know that it will work fine. It's instead magic (out of the human reason) how the kernel works now, if you think that we _need_ atomic_t instead of int.
It's hard for me to be quiet even if you asked me to go away because I think you are plain wrong telling that we need mm->count atomic_t for the future.
Andrea Arcangeli
PS. You have not hurted me asking me to go away, because I _always_ do the _best_ I _can_, and if my best is plain wrong I can't change this reality. What I care is to do the best I can. Maybe I should really go away and do something in my sparetime where it's not requested to be clever... I hope it's not the case though and that you wasn't serious.
- 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/
| |