All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
To: Oleg Nesterov <oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
Cc: Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	"Paul E. McKenney"
	<paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH] Make access to task's nsproxy liter
Date: Fri, 10 Aug 2007 19:09:32 +0400	[thread overview]
Message-ID: <46BC7FAC.2080208@openvz.org> (raw)
In-Reply-To: <20070810140545.GA74-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>

Oleg Nesterov wrote:
> On 08/10, Serge E. Hallyn wrote:
>> Quoting Pavel Emelyanov (xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org):
>>> +/*
>>> + * the namespaces access rules are:
>>> + *
>>> + *  1. only current task is allowed to change tsk->nsproxy pointer or
>>> + *     any pointer on the nsproxy itself
>>> + *
>>> + *  2. when accessing (i.e. reading) current task's namespaces - no
>>> + *     precautions should be taken - just dereference the pointers
>>> + *
>>> + *  3. the access to other task namespaces is 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();
>> And lastly, I guess that the caller to switch_task_namespaces() has
>> to ensure that new_nsproxy either (1) is the init namespace, (2) is a
>> brand-new namespace to which noone else has a reference, or (3) the
>> caller has to hold a reference to the new_nsproxy across the call to
>> switch_task_namespaces().
>>
>> As it happens the current calls fit (1) or (2).  Again if we happen to
>> jump into the game of switching a task into another task's nsproxy,
>> we'll need to be mindful of (3) so that new_nsproxy can't be tossed into
>> the bin between
>>
>> 	if (new)
>> 		get_nsproxy(new);
> 
> 4) Unless tsk == current, get_task_namespaces(tsk) and get_nsproxy(tsk)
>    are racy even if done under rcu_read_lock().

Yup :)

It is already written in comment that only the current is allowed
to change its nsproxy. I.e. when switch_task_nsproxy() is called
for tsk other than current it's a BUG

> Oleg.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@openvz.org>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.osdl.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	devel@openvz.org
Subject: Re: [PATCH] Make access to task's nsproxy liter
Date: Fri, 10 Aug 2007 19:09:32 +0400	[thread overview]
Message-ID: <46BC7FAC.2080208@openvz.org> (raw)
In-Reply-To: <20070810140545.GA74@tv-sign.ru>

Oleg Nesterov wrote:
> On 08/10, Serge E. Hallyn wrote:
>> Quoting Pavel Emelyanov (xemul@openvz.org):
>>> +/*
>>> + * the namespaces access rules are:
>>> + *
>>> + *  1. only current task is allowed to change tsk->nsproxy pointer or
>>> + *     any pointer on the nsproxy itself
>>> + *
>>> + *  2. when accessing (i.e. reading) current task's namespaces - no
>>> + *     precautions should be taken - just dereference the pointers
>>> + *
>>> + *  3. the access to other task namespaces is 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();
>> And lastly, I guess that the caller to switch_task_namespaces() has
>> to ensure that new_nsproxy either (1) is the init namespace, (2) is a
>> brand-new namespace to which noone else has a reference, or (3) the
>> caller has to hold a reference to the new_nsproxy across the call to
>> switch_task_namespaces().
>>
>> As it happens the current calls fit (1) or (2).  Again if we happen to
>> jump into the game of switching a task into another task's nsproxy,
>> we'll need to be mindful of (3) so that new_nsproxy can't be tossed into
>> the bin between
>>
>> 	if (new)
>> 		get_nsproxy(new);
> 
> 4) Unless tsk == current, get_task_namespaces(tsk) and get_nsproxy(tsk)
>    are racy even if done under rcu_read_lock().

Yup :)

It is already written in comment that only the current is allowed
to change its nsproxy. I.e. when switch_task_nsproxy() is called
for tsk other than current it's a BUG

> Oleg.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  parent reply	other threads:[~2007-08-10 15:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-09  9:51 [PATCH] Make access to task's nsproxy liter Pavel Emelyanov
2007-08-09  9:51 ` Pavel Emelyanov
2007-08-10 13:40 ` Serge E. Hallyn
2007-08-10 14:05   ` Oleg Nesterov
2007-08-10 14:15     ` Oleg Nesterov
2007-08-10 14:26       ` Serge E. Hallyn
     [not found]     ` <20070810140545.GA74-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
2007-08-10 15:09       ` Pavel Emelyanov [this message]
2007-08-10 15:09         ` Pavel Emelyanov
2007-08-10 15:30         ` Serge E. Hallyn
2007-08-10 16:45         ` Oleg Nesterov
2007-08-10 18:03           ` Eric W. Biederman
     [not found]             ` <m13ayrxo60.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-08-13 15:01               ` Serge E. Hallyn
2007-08-13 15:01                 ` Serge E. Hallyn

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=46BC7FAC.2080208@openvz.org \
    --to=xemul-gefaqzzx7r8dnm+yrofe0a@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org \
    --cc=paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.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 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.