From: Oleg Nesterov <oleg@redhat.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelyanov <xemul@parallels.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Tejun Heo <tj@kernel.org>, Andrew Vagin <avagin@openvz.org>,
Vasiliy Kulikov <segoon@openwall.com>
Subject: Re: [RFC] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v6
Date: Tue, 17 Jan 2012 18:40:49 +0100 [thread overview]
Message-ID: <20120117174049.GA19268@redhat.com> (raw)
In-Reply-To: <20120116162021.GH2998@moon>
On 01/16, Cyrill Gorcunov wrote:
>
> On Mon, Jan 16, 2012 at 05:11:14PM +0100, Oleg Nesterov wrote:
> > On 01/16, Cyrill Gorcunov wrote:
> > >
> > > +get_children_pid(struct proc_pid_children_iter *iter, struct pid *pid_prev, loff_t pos)
> > > +{
> > > + struct task_struct *start, *task;
> > > + struct pid *pid = NULL;
> > > +
> > > + read_lock(&tasklist_lock);
> > > +
> > > + start = pid_task(iter->pid_start, PIDTYPE_PID);
> > > + if (!start)
> > > + goto out;
> > > +
> > > + /*
> > > + * Lets try to continue searching first, this gives
> > > + * us significant speedup on children-rich processes.
> > > + */
> > > + if (pid_prev) {
> > > + task = pid_task(pid_prev, PIDTYPE_PID);
> > > + if (task && task->real_parent == start &&
> > > + !(list_empty(&task->sibling))) {
> >
> > Damn. No, this is wrong.
> >
> > Damn! Yes, it was we who told you to check list_empty(sibling) ;)
> >
> > But this is not enough. exit_ptrace() can do list_move() without
> > changing ->real_parent.
> >
> > I'll try to think. At first glance we can rely on EXIT_DEAD, but
> > I'd like to avoid this, I think EXIT_DEAD should die.
>
> Ouch! Thanks for catching this Oleg. I'll try to come with something
> to show as well.
Do you see another approach? I don't, so I'd suggest to check
"task->exit_state != EXIT_DEAD" instead of !list_empty().
Just in case, we can also check "start->exit_state == 0" instead
of "task->real_parent == start" with the same effect, up to you.
It would be nice to add the comment explaining these checks...
And I forgot to mention, the comment below
> + /*
> + * We might miss some freshly created children
> + * here, but it was never promised to be
> + * accurate.
> + */
> + if (list_is_last(&task->sibling, &start->children))
> + goto out;
looks misleading. Contrary to the slow path, we can't miss the
freshly forked child here, copy_process() does list_add_tail().
But the slow path obviously can skip much more than needed and
miss children (freshly forked or not), probably it would be better
to move the comment down and remove the "freshly created" part.
What do you think?
Oleg.
next prev parent reply other threads:[~2012-01-17 17:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 15:32 [RFC] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v6 Cyrill Gorcunov
2012-01-16 16:11 ` Oleg Nesterov
2012-01-16 16:20 ` Cyrill Gorcunov
2012-01-17 17:40 ` Oleg Nesterov [this message]
2012-01-17 17:57 ` Cyrill Gorcunov
2012-01-17 18:14 ` Oleg Nesterov
2012-01-17 18:30 ` Cyrill Gorcunov
2012-01-17 21:38 ` KOSAKI Motohiro
2012-01-18 9:43 ` Cyrill Gorcunov
2012-01-18 13:58 ` Oleg Nesterov
2012-01-18 14:21 ` Cyrill Gorcunov
2012-01-18 14:36 ` Oleg Nesterov
2012-01-18 18:23 ` Cyrill Gorcunov
2012-01-18 19:07 ` Cyrill Gorcunov
2012-01-19 14:10 ` Oleg Nesterov
2012-01-19 14:47 ` Cyrill Gorcunov
2012-01-19 15:55 ` Oleg Nesterov
2012-01-19 16:27 ` Cyrill Gorcunov
2012-01-19 16:44 ` Oleg Nesterov
2012-01-19 17:07 ` Cyrill Gorcunov
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=20120117174049.GA19268@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=gorcunov@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=tj@kernel.org \
--cc=xemul@parallels.com \
/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).