Messages in this thread | | | Date | Fri, 29 Jan 1999 10:24:16 -0800 (PST) | From | Linus Torvalds <> | 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 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/
| |