lkml.org 
[lkml]   [1999]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site