public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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