From: Oleg Nesterov <oleg@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alan Cox <alan@linux.intel.com>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] move tty_kref_put() outside of __cleanup_signal()
Date: Fri, 19 Mar 2010 14:09:32 +0100 [thread overview]
Message-ID: <20100319130932.GA19394@redhat.com> (raw)
In-Reply-To: <20100319110837.267458d5@lxorguk.ukuu.org.uk>
On 03/19, Alan Cox wrote:
>
> > > > --- 34-rc1/kernel/exit.c~7_TTY_PUT 2010-03-17 20:05:38.000000000 +0100
> > > > +++ 34-rc1/kernel/exit.c 2010-03-18 22:46:41.000000000 +0100
> > > > @@ -150,6 +150,7 @@ static void __exit_signal(struct task_st
> > > > * see account_group_exec_runtime().
> > > > */
> > > > task_rq_unlock_wait(tsk);
> > > > + tty_kref_put(sig->tty);
> > >
> > > and a sig->tty = NULL assignment to trap races might not go amiss here
> > > perhaps ?
> >
> > Indeed ;)
> >
> > The subsequent patches will do this, we need more changes anyway. Currently
> > this doesn't matter because we are going to kfree() this memory unconditionally.
> > But when we pin ->signal to task_struct, we should clear ->signal->tty before
> > we drop ->siglock, then tty_kref_put().
>
> Ok - yes the moment you start refcounting ->signal that changes (or do you
> expect to free ->tty when you destruct the signals ?)
I think signal->tty should be freed (and nullified under ->siglock) when the
last thread exits.
The goal is to make ->signal immutable, so that it would be always safe to
dereference task->signal if you have a reference to task_struct. But I don't
think get_task_struct() should defer tty_kref_put(), and besides put_task_struct()
must be safe in any context.
See also http://marc.info/?l=linux-kernel&m=126885423426183
Oleg.
next prev parent reply other threads:[~2010-03-19 13:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 22:37 [PATCH] move tty_kref_put() outside of __cleanup_signal() Oleg Nesterov
2010-03-18 22:51 ` Alan Cox
2010-03-18 23:16 ` Oleg Nesterov
2010-03-19 11:08 ` Alan Cox
2010-03-19 13:09 ` Oleg Nesterov [this message]
2010-04-08 2:15 ` Roland McGrath
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=20100319130932.GA19394@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox