From: Oleg Nesterov <oleg@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Frank Mayhar <fmayhar@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
adobriyan@gmail.com, Doug Chapman <doug.chapman@hp.com>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] for account_group_exec_runtime(), make sure ->signal can't be freed under rq->lock
Date: Tue, 11 Nov 2008 13:58:44 +0100 [thread overview]
Message-ID: <20081111125844.GB3503@redhat.com> (raw)
In-Reply-To: <20081111103532.GA8869@elte.hu>
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.
next prev parent reply other threads:[~2008-11-11 11:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-10 14:39 [PATCH] for account_group_exec_runtime(), make sure ->signal can't be freed under rq->lock Oleg Nesterov
2008-11-11 10:35 ` Ingo Molnar
2008-11-11 12:58 ` Oleg Nesterov [this message]
2008-11-11 17:10 ` Frank Mayhar
2008-11-11 17:16 ` Ingo Molnar
2008-11-11 17:28 ` Frank Mayhar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081111125844.GB3503@redhat.com \
--to=oleg@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=doug.chapman@hp.com \
--cc=fmayhar@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.