Messages in this thread | | | Date | Tue, 11 Nov 2008 13:58:44 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH] for account_group_exec_runtime(), make sure ->signal can't be freed under rq->lock |
| |
On 11/11, Ingo Molnar wrote: > > * Oleg Nesterov <oleg@redhat.com> wrote: > > > The patch is ugly, but I don't see the better fix for now. Needs the > > review from Peter/Ingo. > > this is indeed too ugly,
Agreed. It was "unless we find another fix for 2.6.28".
> Regarding this teardown bug. Stupid question: why cannot the signal > structure live as long as the last user is around? It's a tiny amount > of RAM.
Well, release_task()->__exit_signal() clears/frees ->signal exactly because it doesn't (must not) have users any longer. And we have the code which checks ->signal != NULL to know if the task was already released or not.
Now scheduler wants to play with ->signal. We can change the code so that we don't actually free it until the task does the last schedule. Say, we can free it __from put_task_struct(). But this means we need another counter in signal_struct (signal_struct->count can't work). And, until we change the code which checks ->signal != NULL, we need another pointer in task_struct.
Perhaps this makes sense regardless of this bug, but I don't think this is 2.6.28 material anyway.
Oleg.
| |