Messages in this thread Patch in this message |  | | | Date | Mon, 22 Mar 2010 19:41:27 +0100 | | From | Oleg Nesterov <> | | 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.
|  |