linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
Cc: linux-kernel@vger.kernel.org, serge.hallyn@canonical.com,
	akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
	davem@davemloft.net, cmetcalf@tilera.com,
	paulmck@linux.vnet.ibm.com
Subject: Re: [RFC PATCH linux-next v2] ns: do not allocate a new nsproxy at each call
Date: Tue, 22 Oct 2013 12:44:20 -0700	[thread overview]
Message-ID: <87iowprsyz.fsf@xmission.com> (raw)
In-Reply-To: <8761spw3an.fsf@xmission.com> (Eric W. Biederman's message of "Tue, 22 Oct 2013 11:47:44 -0700")


To be succint.

Mutation of nsproxy in place was a distraction.

What is crucial to the current operation of the code is

synchronize_rcu();
put_pid_ns();
put_net_ns();
...

To remove the syncrhonize_rcu we would have to either user call_rcu or
make certain all of the namespaces have some kind of rcu liveness
guarantee (which many of them do) and use something like maybe_get_net.

If you are going to pursue this the maybe_get_net direction is my
preference as that is what we would need if we did not have nsproxy
and so will be simpler overall.

Hmm.  On the side of simple it may be appropriate to revisit the patch
that started using rcu protection for nsproxy.   I doesn't look like
the original reasons for nsproxy being rcu protected exist any more,
so reverting to task_lock protect may be enough..

And it would result in faster/simpler code that only slows down when we
perform a remote access, which should be far from common.

commit cf7b708c8d1d7a27736771bcf4c457b332b0f818
Author: Pavel Emelyanov <xemul@openvz.org>
Date:   Thu Oct 18 23:39:54 2007 -0700

    Make access to task's nsproxy lighter
    
    When someone wants to deal with some other taks's namespaces it has to lock
    the task and then to get the desired namespace if the one exists.  This is
    slow on read-only paths and may be impossible in some cases.
    
    E.g.  Oleg recently noticed a race between unshare() and the (sent for
    review in cgroups) pid namespaces - when the task notifies the parent it
    has to know the parent's namespace, but taking the task_lock() is
    impossible there - the code is under write locked tasklist lock.
    
    On the other hand switching the namespace on task (daemonize) and releasing
    the namespace (after the last task exit) is rather rare operation and we
    can sacrifice its speed to solve the issues above.
    
    The access to other task namespaces is proposed to be performed
    like this:
    
         rcu_read_lock();
         nsproxy = task_nsproxy(tsk);
         if (nsproxy != NULL) {
                 / *
                   * work with the namespaces here
                   * e.g. get the reference on one of them
                   * /
         } / *
             * NULL task_nsproxy() means that this task is
             * almost dead (zombie)
             * /
         rcu_read_unlock();
    
    This patch has passed the review by Eric and Oleg :) and,
    of course, tested.


Eric

  reply	other threads:[~2013-10-22 19:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 17:35 [RFC PATCH linux-next] ns: do not allocate a new nsproxy at each call Guillaume Gaudonville
2013-10-15 18:40 ` Eric W. Biederman
2013-10-16  8:48   ` Guillaume Gaudonville
2013-10-16 19:42     ` Eric W. Biederman
2013-10-18 14:46       ` [RFC PATCH linux-next v2] " Guillaume Gaudonville
2013-10-18 22:34         ` Eric W. Biederman
2013-10-22 15:52           ` Guillaume Gaudonville
2013-10-22 16:53             ` Paul E. McKenney
2013-10-22 18:47               ` Eric W. Biederman
2013-10-22 19:44                 ` Eric W. Biederman [this message]
2013-10-22 21:42                   ` Paul E. McKenney
2013-10-23  8:27                   ` Guillaume Gaudonville

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=87iowprsyz.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=cmetcalf@tilera.com \
    --cc=davem@davemloft.net \
    --cc=guillaume.gaudonville@6wind.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=serge.hallyn@canonical.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).