[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111207190340.GP21678@moon>
Date: Wed, 7 Dec 2011 23:03:40 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Pavel Emelyanov <xemul@...allels.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Tejun Heo <tj@...nel.org>,
Vasiliy Kulikov <segoon@...nwall.com>,
Andrew Vagin <avagin@...nvz.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fs, proc: Introduce the /proc/<pid>/children entry v2
On Wed, Dec 07, 2011 at 07:53:43PM +0100, Oleg Nesterov wrote:
> Hi Cyrill,
>
> Sorry, I didn't read this patch yet, but
>
> On 12/06, Cyrill Gorcunov wrote:
> >
> > +static void *children_seq_start(struct seq_file *seq, loff_t *pos)
> > +{
> > + struct task_struct *task;
> > +
> > + rcu_read_lock();
> > + task = seq->private;
> > + if (task)
> > + return seq_list_start(&task->children, *pos);
>
> This looks "obviously wrong".
>
> We can not trust ->children->next after rcu_read_unlock(). Another
> rcu_read_lock() can't help.
>
> Once again, I can be easily wrong, need to read the patch first.
>
Wait, Oleg, I might be wrong as well, but it's now as
children_seq_open
get_proc_task (so ref to task increased)
the children_seq_start/children_seq_stop works
in iteration and every new iteration seq_list_next
walks over the whole children list from the list
head under rcu lock, so even if task is removed
or added the link should exsist until rcu is unlocked
and sync'ed no?
Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists