lkml.org 
[lkml]   [2010]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[PATCH -mm 0/3] proc: task->signal can't be NULL
    With the recent changes in -mm it is always safe to dereference
    task->signal. It can't be NULL and it is pinned to task_struct.

    fs/proc becomes the only valid user of signal->count which should
    either die or become "int nr_threads".


    Alexey, Eric.

    Can't we kill this counter? Afaics, get_nr_threads() doesn't need to
    be "precise", we probably can estimate the number of threads using
    signal->live (yes sure, we can't use ->live as nr_threads).

    Except: first_tid() uses get_nr_threads() for optimization. Is this
    optimization really important? Afaics, it only helps in the unlikely
    case, probably in that case the extra lockless while_each_thread()
    doesn't hurt.

    IOW, how about

    --- a/fs/proc/base.c
    +++ b/fs/proc/base.c
    @@ -3071,11 +3071,6 @@ static struct task_struct *first_tid(str
    goto found;
    }

    - /* If nr exceeds the number of threads there is nothing todo */
    - pos = NULL;
    - if (nr && nr >= get_nr_threads(leader))
    - goto out;
    -
    /* If we haven't found our starting place yet start
    * with the leader and walk nr threads forward.
    */

    ?

    Not that I think it is terribly important to kill this counter, and
    probably signal->nr_threads can make sense anyway, so far I am just
    curious.

    Oleg.



    \
     
     \ /
      Last update: 2010-03-22 19:45    [W:0.022 / U:30.312 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site