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"
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Serge Hallyn
<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@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: Thu, 9 Oct 2014 23:34:14 +0200 [thread overview]
Message-ID: <20141009213414.GA10705@redhat.com> (raw)
In-Reply-To: <5871495633F38949900D2BF2DC04883E5E1649-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
On 10/09, Chen, Hanxiao wrote:
>
> > From: Oleg Nesterov [mailto:oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> >
> > Hmm. We only want the tasks from our namespace, yes? Perhaps find_ge_pid()
> > makes more sense?
>
> Only tasks from our ns is valid.
> But how could find_ge_pid() do that?
>
> nr = 1;
> while (nr < PID_MAX_LIMIT) {
> find_ge_pid(nr, curr_ns);
> list_add();
> nr++;
> }
something like this, except list_add() should obviously depend on
is_child_reaper() check.
This can be more optimal in sub-namespaces, you do not need to abuse
the global process list.
And if you change this code to use get_pid/put_pid, then you do not
need to hold rcu_read_lock() throughout, you only need it around
find_ge_pid + get_pid.
At the same time, for_each_process() in the global namespace can be
faster if there are a lot of sub-threads.
> Perhaps that's not a good way.
OK, I won't insist.
although it would be nice to know why do you think this is bad.
> > > + pid = task_pid(p);
> >
> > Well, in theory you need barrier() here. Or perhaps we should add
> > ACCESS_ONCE() into task_pid()...
>
> You mean modify task_pid as:
> return ACCESS_ONCE(task->pids[PIDTYPE_PID].pid;);
Yes. But not now an not in this patch of course. I'd suggest to add
barrier() just in case.
> > And imho it would be better to declare pidns_list/pidns_tree locally
> > in nslist_proc_show() and pass them to the callees.
>
> That's a good idea.
> Will changed in the next version.
Good. And I forgot to mention, in this case you do not need pidns_list_lock
at all afaics.
Oleg.
next prev parent reply other threads:[~2014-10-09 21:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 9:56 [PATCHv4] procfs: show hierarchy of pid namespace Chen Hanxiao
[not found] ` <1412762198-21825-1-git-send-email-chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2014-10-08 10:34 ` Richard Weinberger
[not found] ` <5435134E.1080802-/L3Ra7n9ekc@public.gmane.org>
2014-10-09 9:01 ` Chen, Hanxiao
2014-10-08 15:13 ` Oleg Nesterov
[not found] ` <20141008151328.GB4835-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-09 10:02 ` Chen, Hanxiao
[not found] ` <5871495633F38949900D2BF2DC04883E5E1649-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
2014-10-09 21:34 ` Oleg Nesterov [this message]
[not found] ` <20141009213414.GA10705-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-13 10:13 ` Chen, Hanxiao
[not found] ` <5871495633F38949900D2BF2DC04883E5E864C@G08CNEXMBPEKD02.g08.fujitsu.local>
[not found] ` <5871495633F38949900D2BF2DC04883E5E864C-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
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=20141009213414.GA10705@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox