Messages in this thread |  | | | Subject | Re: [PATCH -mm 0/3] proc: task->signal can't be NULL | | From | (Eric W. Biederman) | | Date | Tue, 23 Mar 2010 13:53:26 -0700 |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 03/22, Eric W. Biederman wrote: >> >> Oleg Nesterov <oleg@redhat.com> writes: > > If a bad user passes the large f_pos > nr_threads then this check > eliminates the unneeded while_each_thread() loop, yes. But it can use > f_pos == nr_threads and provoke the same loop? > > Or. just do rewinddir() + readdir(big_count). Now we walk through the > list and call proc_task_fill_cache() for each entry. > > IOW, I don't understand how this check can help from the DOS pov.
It can't. I just want it to be able to ;)
>> However: >> proc_task_getattr uses get_nr_threads to get it's nlink count correct. > > Yes. But we don't need the exactly precise number here if we are > racing with fork/exit ? > >> Not walking the thread list to get the number of threads seems like an >> important cpu time saving measure. > > Not sure I understand... Also, first_tid() could use sig->sigcnt (the > reference counter) instead of sig->count. This is not the same, but I > think in practice this is fine.
We need a value that can be computed in constant time, and is not correct except when the number of threads is actively changing.
> OK. Let's keep this counter as "int nr_thread". > > Besides, when I tried to re-implement get_nr_threads() using signal->live > I got the really ugly result ;)
Sounds good.
Eric
|  |