From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Chen Hanxiao <chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Cc: Richard Weinberger
<richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Serge Hallyn
<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mateusz Guzik <mguzik-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCHv4] procfs: show hierarchy of pid namespace
Date: Wed, 8 Oct 2014 17:13:28 +0200 [thread overview]
Message-ID: <20141008151328.GB4835@redhat.com> (raw)
In-Reply-To: <1412762198-21825-1-git-send-email-chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Sorry if this was already discussed, I have to admit that I ignored
the previous discussion ;) And it is possible I misread this patch
completely.
On 10/08, Chen Hanxiao wrote:
>
> This patch will show the hierarchy of pid namespace
> by /proc/pidns_hierarchy like:
>
> [root@localhost ~]#cat /proc/pidns_hierarchy
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1534/ns/pid
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1600/ns/pid
> /proc/1550/ns/pid
Well, personally I too think that the filenames look a bit strange,
can't it just print the numbers?
And, iiuc what this patch does... perhaps in this case we should
simply add "struct list_head children" into struct pid_namespace?
In this case the patch will be really simple. I dunno.
> +pidns_list_add(struct pid *pid, struct list_head *list_head,
> + struct pid_namespace *curr_ns)
> +{
> + struct pidns_list *ent;
> + struct pid_namespace *ns;
> +
> + if (is_child_reaper(pid)) {
> + ent = kmalloc(sizeof(*ent), GFP_KERNEL);
GFP_KERNEL under rcu_read_lock(). This is not safe without
CONFIG_PREEMPT_RCU.
> + if (!ent)
> + return -ENOMEM;
> +
> + ent->pid = pid;
> + ns = pid->numbers[pid->level].ns;
> + if (curr_ns) {
> + /* add pids who is the child of curr_ns */
> + for (; ns != NULL; ns = ns->parent)
> + if (ns == curr_ns)
> + list_add_tail(&ent->list, list_head);
afaics, it doesn't make sense to continue after list_add() ?
> +static int proc_pidns_list_refresh(struct pid_namespace *curr_ns)
> +{
> + struct pid *pid;
> + struct task_struct *p;
> + int rc;
> +
> + /* collect pid in differet ns */
> + for_each_process(p) {
Hmm. We only want the tasks from our namespace, yes? Perhaps find_ge_pid()
makes more sense?
> + pid = task_pid(p);
Well, in theory you need barrier() here. Or perhaps we should add
ACCESS_ONCE() into task_pid()...
And imho it would be better to declare pidns_list/pidns_tree locally
in nslist_proc_show() and pass them to the callees.
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Cc: containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Serge Hallyn <serge.hallyn@ubuntu.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
David Howells <dhowells@redhat.com>,
Richard Weinberger <richard.weinberger@gmail.com>,
Pavel Emelyanov <xemul@parallels.com>,
Vasiliy Kulikov <segooon@gmail.com>,
Mateusz Guzik <mguzik@redhat.com>
Subject: Re: [PATCHv4] procfs: show hierarchy of pid namespace
Date: Wed, 8 Oct 2014 17:13:28 +0200 [thread overview]
Message-ID: <20141008151328.GB4835@redhat.com> (raw)
In-Reply-To: <1412762198-21825-1-git-send-email-chenhanxiao@cn.fujitsu.com>
Sorry if this was already discussed, I have to admit that I ignored
the previous discussion ;) And it is possible I misread this patch
completely.
On 10/08, Chen Hanxiao wrote:
>
> This patch will show the hierarchy of pid namespace
> by /proc/pidns_hierarchy like:
>
> [root@localhost ~]#cat /proc/pidns_hierarchy
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1534/ns/pid
> /proc/18060/ns/pid /proc/18102/ns/pid /proc/1600/ns/pid
> /proc/1550/ns/pid
Well, personally I too think that the filenames look a bit strange,
can't it just print the numbers?
And, iiuc what this patch does... perhaps in this case we should
simply add "struct list_head children" into struct pid_namespace?
In this case the patch will be really simple. I dunno.
> +pidns_list_add(struct pid *pid, struct list_head *list_head,
> + struct pid_namespace *curr_ns)
> +{
> + struct pidns_list *ent;
> + struct pid_namespace *ns;
> +
> + if (is_child_reaper(pid)) {
> + ent = kmalloc(sizeof(*ent), GFP_KERNEL);
GFP_KERNEL under rcu_read_lock(). This is not safe without
CONFIG_PREEMPT_RCU.
> + if (!ent)
> + return -ENOMEM;
> +
> + ent->pid = pid;
> + ns = pid->numbers[pid->level].ns;
> + if (curr_ns) {
> + /* add pids who is the child of curr_ns */
> + for (; ns != NULL; ns = ns->parent)
> + if (ns == curr_ns)
> + list_add_tail(&ent->list, list_head);
afaics, it doesn't make sense to continue after list_add() ?
> +static int proc_pidns_list_refresh(struct pid_namespace *curr_ns)
> +{
> + struct pid *pid;
> + struct task_struct *p;
> + int rc;
> +
> + /* collect pid in differet ns */
> + for_each_process(p) {
Hmm. We only want the tasks from our namespace, yes? Perhaps find_ge_pid()
makes more sense?
> + pid = task_pid(p);
Well, in theory you need barrier() here. Or perhaps we should add
ACCESS_ONCE() into task_pid()...
And imho it would be better to declare pidns_list/pidns_tree locally
in nslist_proc_show() and pass them to the callees.
Oleg.
next prev parent reply other threads:[~2014-10-08 15:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 9:56 [PATCHv4] procfs: show hierarchy of pid namespace Chen Hanxiao
2014-10-08 9:56 ` Chen Hanxiao
[not found] ` <1412762198-21825-1-git-send-email-chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2014-10-08 10:34 ` Richard Weinberger
2014-10-08 10:34 ` Richard Weinberger
[not found] ` <5435134E.1080802-/L3Ra7n9ekc@public.gmane.org>
2014-10-09 9:01 ` Chen, Hanxiao
2014-10-09 9:01 ` Chen, Hanxiao
2014-10-08 15:13 ` Oleg Nesterov [this message]
2014-10-08 15:13 ` Oleg Nesterov
[not found] ` <20141008151328.GB4835-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-09 10:02 ` Chen, Hanxiao
2014-10-09 10:02 ` Chen, Hanxiao
[not found] ` <5871495633F38949900D2BF2DC04883E5E1649-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
2014-10-09 21:34 ` Oleg Nesterov
2014-10-09 21:34 ` Oleg Nesterov
[not found] ` <20141009213414.GA10705-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-13 10:13 ` Chen, Hanxiao
2014-10-13 10:13 ` Chen, Hanxiao
[not found] ` <5871495633F38949900D2BF2DC04883E5E864C-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
2014-10-14 17:42 ` Oleg Nesterov
2014-10-14 17:42 ` Oleg Nesterov
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=20141008151328.GB4835@redhat.com \
--to=oleg-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mguzik-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@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.