lkml.org 
[lkml]   [2006]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/6] fill_tgid: fix task_struct leak and possible oops
On 10/30, Balbir Singh wrote:
>
> Oleg Nesterov wrote:
>
> > 2. release_task(first) can happen after fill_tgid() drops tasklist_lock,
> > it is unsafe to dereference first->signal.
> >
>
> But, we have a reference to first via get_task_struct(). release_task()
> would do just a put_task_struct(). Am I missing something?

No, release_task() will reap the task. tsk->usage protects only task_struct
itself (more precisely, it protects against __put_task_struct()). And please
note that release_task()->__exit_signal() sets tsk->signal = NULL.


QUESTION: taskstats_exit_alloc() does kfree(kmem_cache_alloc()), is it OK?
Yes, it works, but is it good? The comment says:

* @objp: pointer returned by kmalloc.


Another question,

do_exit()
taskstats_exit_alloc()
...
taskstats_exit_send()
taskstats_exit_free()

What is the point? Why can't we have taskstats_exit() which does alloc+send+free
itself? This looks like unnecessary complication to me.

From taskstats_exit_alloc:

/*
* This is the cpu on which the task is exiting currently and will
* be the one for which the exit event is sent, even if the cpu
* on which this function is running changes later.
*/

Why do we record current cpu exactly here? This task probably changed its
CPU many times since it entered sys_exit(), so what is the problem if it
will change CPU again before taskstats_exit_send() ?

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-30 21:37    [W:0.040 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site