From: sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
To: Oleg Nesterov <oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
Cc: Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
Pavel Emelianov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH 2/3] Pid ns helpers for signals
Date: Mon, 3 Sep 2007 09:55:14 -0700 [thread overview]
Message-ID: <20070903165514.GC2793@us.ibm.com> (raw)
In-Reply-To: <20070901112903.GD191-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
Oleg Nesterov [oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org] wrote:
| On 08/31, sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
| >
| > Define some helper functions that will be used to implement signal semantics
| > with multiple pid namespaces.
| >
| > is_current_in_ancestor_pid_ns(task)
| >
| > TRUE iff active pid namespace of 'current' is an ancestor of
| > active pid namespace of @task.
| >
| > is_current_in_same_or_ancestor_pid_ns(task)
| >
| > TRUE iff active pid namespace of 'current' is either same as
| > or an ancestor of active pid namespace of @task.
|
| These names are awfull :) Yes, yes, it was me who suggested them... No, I can't
| suggest something better.
I agree :-) I tried smaller names like task_ancestor_pid_ns() and passing in
'current' as a parameter so its not in the name :-) but the functionality was
not obvious from the names.
|
| > + * Caller must hold a reference to @pid.
| > + */
| > +static inline struct pid_namespace *pid_active_ns(struct pid *pid)
| > +{
| > + if (!pid)
| > + return NULL;
| > +
| > + return pid->numbers[pid->level].ns;
| > +}
|
| Well, the comment is a bit misleading. Yes, my previous comment was not very
| clear. Yes, the function itself is not safe unless you know what are you doing,
| like, for example, get_pid(). I think it is better to just kill the comment.
| Please see below.
Ok. will remove the comment.
|
| > +static struct pid_namespace *get_task_pid_ns(struct task_struct *tsk)
| > +{
| > + struct pid *pid;
| > + struct pid_namespace *ns;
| > +
| > + pid = get_task_pid(tsk, PIDTYPE_PID);
| > + ns = get_pid_ns(pid_active_ns(pid));
| > + put_pid(pid);
| > +
| > + return ns;
| > +}
|
| Hmm. Firstly, we don't need this for the "current", but all users of this func
| also do get_task_pid_ns(current).
|
| Also, we don't need get/put_pid. rcu locks are enough,
|
| rcu_read_lock();
| ns = get_pid_ns(pid_active_ns(task_pid(tks)));
| rcu_read_unlock();
|
Ok.
| However, do we really need this complications right now? Currently, we use
| this "compare namespaces" helpers only when we know that "struct pid" is
| stable. We are sending the signal to that task, it must be pid_alive(), and
| we either locked the task itself, or we hold tasklist.
My concern was that the task could detach and free its pid which in turn
would drop the last reference on a pid namespace and free it.
By trying to keep is_current_in_ancestor*() general, I guess it is more
complicated than it needs to be right now.
Would holding the rcu_read_lock() be enough or since our callers hold
it now, can we just drop that too ?
is_current_in_ancstor_pid_ns(tsk)
rcu_read_lock();
my_ns = pid_active_ns(current);
tsk_ns = pid_active_ns(tsk)
rc = is_ancestor_ns(my_ns, tsk_ns)
rcu_read_unlock();
return rc;
Thanks for the comments,
Suka
next prev parent reply other threads:[~2007-09-03 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-31 20:36 [PATCH 2/3] Pid ns helpers for signals sukadev-r/Jw6+rmf7HQT0dZR+AlfA
[not found] ` <20070831203634.GB3268-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-09-01 11:29 ` Oleg Nesterov
[not found] ` <20070901112903.GD191-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
2007-09-01 11:56 ` Oleg Nesterov
[not found] ` <20070901115601.GA258-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org>
2007-09-03 16:01 ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA
[not found] ` <20070903160147.GB2793-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-09-03 16:24 ` Oleg Nesterov
2007-09-03 16:55 ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA [this message]
[not found] ` <20070903165514.GC2793-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-09-03 17:14 ` Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2007-09-11 4:11 sukadev-r/Jw6+rmf7HQT0dZR+AlfA
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=20070903165514.GC2793@us.ibm.com \
--to=sukadev-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=oleg-6lXkIZvqkOAvJsYlp49lxw@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@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.