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


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

     \ /
      Last update: 2005-03-22 13:50    [W:0.038 / U:16.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site