From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: oleg@redhat.com, ebiederm@xmission.com, roland@redhat.com,
containers@lists.osdl.org, linux-kernel@vger.kernel.org,
xemul@openvz.org
Subject: Re: [RFC][PATCH 2/5] pid: Generalize task_active_pid_ns
Date: Mon, 1 Dec 2008 12:38:40 -0800 [thread overview]
Message-ID: <20081201203840.GA15004@us.ibm.com> (raw)
In-Reply-To: <1227791371.2615.109.camel@frecb000730.frec.bull.fr>
Nadia Derbey [Nadia.Derbey@bull.net] wrote:
| On Tue, 2008-11-25 at 19:45 -0800, Sukadev Bhattiprolu wrote:
| > >From 7f7caaa9d9014d7230dc0b1e0f75536f0b6ccdbf Mon Sep 17 00:00:00 2001
| > From: Eric W. Biederman <ebiederm@xmission.com>
| > Date: Mon, 10 Nov 2008 19:12:02 -0800
| > Subject: [PATCH 2/5] pid: Generalize task_active_pid_ns
| >
| > Currently task_active_pid_ns is not safe to call after a
| > task becomes a zombie and exit_task_namespaces is called,
| > as nsproxy becomes NULL. By reading the pid namespace from
| > the pid of the task we can trivially solve this problem at
| > the cost of one extra memory read in what should be the
| > same cacheline as we read the namespace from.
| >
| > When moving things around I have made task_active_pid_ns
| > out of line because keeping it in pid_namespace.h would
| > require adding includes of pid.h and sched.h that I
| > don't think we want.
| >
| > This change does make task_active_pid_ns unsafe to call during
| > copy_process until we attach a pid on the task_struct which
| > seems to be a reasonable trade off.
| >
| > Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
| > ---
| > include/linux/pid_namespace.h | 6 +-----
| > kernel/fork.c | 4 ++--
| > kernel/pid.c | 6 ++++++
| > 3 files changed, 9 insertions(+), 7 deletions(-)
| >
| > diff --git a/include/linux/pid_namespace.h b/include/linux/pid_namespace.h
| > index d82fe82..38d1032 100644
| > --- a/include/linux/pid_namespace.h
| > +++ b/include/linux/pid_namespace.h
| > @@ -79,11 +79,7 @@ static inline void zap_pid_ns_processes(struct pid_namespace *ns)
| > }
| > #endif /* CONFIG_PID_NS */
| >
| > -static inline struct pid_namespace *task_active_pid_ns(struct task_struct *tsk)
| > -{
| > - return tsk->nsproxy->pid_ns;
| > -}
| > -
| > +extern struct pid_namespace *task_active_pid_ns(struct task_struct *tsk);
| > void pidhash_init(void);
| > void pidmap_init(void);
| >
| > diff --git a/kernel/fork.c b/kernel/fork.c
| > index f608356..28be39a 100644
| > --- a/kernel/fork.c
| > +++ b/kernel/fork.c
| > @@ -1111,12 +1111,12 @@ static struct task_struct *copy_process(unsigned long clone_flags,
| >
|
| Suka,
|
| I'm wondering if it is still safe to keep the call to
| task_active_pid_ns() in create_new_namespaces(): copy_namespaces() is
| called a couple of lines above this sequence and it calls
| create_new_namespaces(). So I don't see why you're now referencing
| p->nsproxy->pid_ns here and not in create_new_namespaces()?
It is safe to use the new task_active_pid_ns() when the process has
a valid (fully initialized) 'struct pid'. copy_namespaces() and
create_new_namespaces() operate on the _parent's_ 'struct pid' which
is valid.
|
| Regards,
| Nadia
|
| > if (pid != &init_struct_pid) {
| > retval = -ENOMEM;
| > - pid = alloc_pid(task_active_pid_ns(p));
| > + pid = alloc_pid(p->nsproxy->pid_ns);
Here, at the call to task_active_pid_ns(), child does not have a
'struct pid' - we are just allocating it. So its important that
this use the pid_ns from nsproxy.
| > if (!pid)
| > goto bad_fork_cleanup_io;
| >
| > if (clone_flags & CLONE_NEWPID) {
| > - retval = pid_ns_prepare_proc(task_active_pid_ns(p));
| > + retval = pid_ns_prepare_proc(p->nsproxy->pid_ns);
| > if (retval < 0)
| > goto bad_fork_free_pid;
| > }
| > diff --git a/kernel/pid.c b/kernel/pid.c
| > index 064e76a..c5513fe 100644
| > --- a/kernel/pid.c
| > +++ b/kernel/pid.c
| > @@ -474,6 +474,12 @@ pid_t task_session_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
| > }
| > EXPORT_SYMBOL(task_session_nr_ns);
| >
| > +struct pid_namespace *task_active_pid_ns(struct task_struct *tsk)
| > +{
| > + return ns_of_pid(task_pid(tsk));
| > +}
| > +EXPORT_SYMBOL_GPL(task_active_pid_ns);
| > +
| > /*
| > * Used by proc to find the first pid that is greater then or equal to nr.
| > *
| --
| Nadia Derbey <Nadia.Derbey@bull.net>
next prev parent reply other threads:[~2008-12-01 20:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 3:42 [RFC][PATCH 0/5] Container init signal semantics Sukadev Bhattiprolu
2008-11-26 3:44 ` [RFC][PATCH 1/5] pid: Implement ns_of_pid Sukadev Bhattiprolu
2008-11-27 1:19 ` Bastian Blank
2008-12-01 20:24 ` Sukadev Bhattiprolu
2008-12-02 11:58 ` Bastian Blank
2008-12-02 22:12 ` Sukadev Bhattiprolu
2008-12-03 0:34 ` Valdis.Kletnieks
2008-11-26 3:45 ` [RFC][PATCH 2/5] pid: Generalize task_active_pid_ns Sukadev Bhattiprolu
2008-11-27 1:17 ` Bastian Blank
2008-11-27 21:19 ` Greg Kurz
2008-12-01 21:15 ` Sukadev Bhattiprolu
2008-12-02 11:57 ` Bastian Blank
2008-12-03 7:41 ` Sukadev Bhattiprolu
2008-12-04 12:58 ` Bastian Blank
2008-11-27 13:09 ` Nadia Derbey
2008-12-01 20:38 ` Sukadev Bhattiprolu [this message]
2008-11-26 3:46 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Sukadev Bhattiprolu
2008-11-27 1:01 ` Bastian Blank
2008-12-01 20:15 ` Sukadev Bhattiprolu
2008-12-02 11:48 ` Bastian Blank
2008-12-02 19:59 ` Sukadev Bhattiprolu
2008-12-04 12:45 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns+ Bastian Blank
2008-12-02 3:07 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Roland McGrath
2008-12-04 1:06 ` Roland McGrath
2008-12-09 3:22 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 4/5] Protect cinit from fatal signals Sukadev Bhattiprolu
2008-11-27 1:07 ` Bastian Blank
2008-12-01 20:21 ` Sukadev Bhattiprolu
2008-12-02 12:06 ` Bastian Blank
2008-12-02 20:51 ` Sukadev Bhattiprolu
2008-12-04 12:52 ` Bastian Blank
2008-12-04 18:58 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 5/5] Clear si_pid for signal from ancestor ns Sukadev Bhattiprolu
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=20081201203840.GA15004@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=Nadia.Derbey@bull.net \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=xemul@openvz.org \
/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