Re: [patch] fixed both processes in D state and the /proc/ oopses [Re: [patch] Fixed the race that w

Linus Torvalds (torvalds@transmeta.com)
Fri, 29 Jan 1999 10:24:16 -0800 (PST)


On Fri, 29 Jan 1999, Andrea Arcangeli wrote:
>
> > If you want to touch some _other_ process mm pointer, that's when it gets
> > interesting. Buyer beware.
>
> Infact this is the point. I really think you are missing something. I read
> your explanation of why we only need atomic_t but it was not touching some
> point I instead thought about.
>
> Ok, I assume you are right. Please take this example: I am writing a nice
> kernel module that will collect some nice stats from the kernel.

And that's where you have problems. You shouldn't do that, and that's why
/proc is such a nasty beast right now.

If you want to look at other peoples processes, then the onus should be on
_you_ to do all the extra crap that normal processes do not need to do.
That extra crap can be a number of things, but you shouldn't penalize the
normal path (which is to touch only your own mm space).

For example, the thing I suspect we'll have to do in the long run for
/proc is:

- get the process while holding the tasklist lock, and increment the page
count so that even if the process exists, the page does not get unused.
- get the kernel lock. Now we know that we're atomic with regard to
__exit_mm()
- look at tsk->mm: it it is not init_mm, you're now safe, because
__exit_mm is called only with the kernel lock held.

See? No spinlocks.

Linus

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