From: Frederic Weisbecker <fweisbec@gmail.com>
To: Mandeep Baines <msb@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Don Zickus <dzickus@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Jerome Marchand <jmarchan@redhat.com>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org, stable@kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: while_each_thread() under rcu_read_lock() is broken?
Date: Sat, 19 Jun 2010 07:35:25 +0200 [thread overview]
Message-ID: <20100619053522.GA11264@nowhere> (raw)
In-Reply-To: <AANLkTimh-7F4VK8FI6j-JQ4EDnxtEI3ZlGY-2X-lq6iM@mail.gmail.com>
On Fri, Jun 18, 2010 at 10:00:54PM -0700, Mandeep Baines wrote:
> On Fri, Jun 18, 2010 at 12:34 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > (add cc's)
> >
> > Hmm. Once I sent this patch, I suddenly realized with horror that
> > while_each_thread() is NOT safe under rcu_read_lock(). Both
> > do_each_thread/while_each_thread or do/while_each_thread() can
> > race with exec().
> >
> > Yes, it is safe to do next_thread() or next_task(). But:
> >
> > #define while_each_thread(g, t) \
> > while ((t = next_thread(t)) != g)
> >
> > suppose that t is not the group leader, and it does de_thread() and then
> > release_task(g). After that next_thread(t) returns t, not g, and the loop
> > will never stop.
> >
> > I _really_ hope I missed something, will recheck tomorrow with the fresh
> > head. Still I'd like to share my concerns...
> >
>
> Yep. You're right. Not sure what I was thinking. This is only case
> where do_each_thread
> is protected by an rcu_read_lock. All others, correctly use read_lock.
cgroup does too.
taskstats also uses rcu with while_each_threads, and may be some
others.
It's not your fault, theses iterators are supposed to be rcu safe,
we are just encountering a bad race :)
> > If I am right, probably we can fix this, something like
> >
> > #define while_each_thread(g, t) \
> > while ((t = next_thread(t)) != g && pid_alive(g))
> >
>
> This seems like a reasonable approach. Maybe call it:
>
> while_each_thread_maybe_rcu() :)
Hmm, no while_each_thread must really be rcu_safe.
>
> This makes hung_task a little less useful for failure fencing since
> this (and rcu_lock_break)
> increases the potential for never examining all threads but its still
> a nice lightweight diagnostic
> for finding bugs.
In fact may be we could just drop the rcu break, people who really
care about latencies can use the preemptable version.
I know the worry is more about delaying too much the grace period if
we walk a too long task list, but I don't think it's really a problem.
next prev parent reply other threads:[~2010-06-19 5:35 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-18 19:02 [PATCH] fix the racy check_hung_uninterruptible_tasks()->rcu_lock_break() logic Oleg Nesterov
2010-06-18 19:34 ` while_each_thread() under rcu_read_lock() is broken? Oleg Nesterov
2010-06-18 21:08 ` Roland McGrath
2010-06-18 22:37 ` Oleg Nesterov
2010-06-18 22:33 ` Paul E. McKenney
2010-06-21 17:09 ` Oleg Nesterov
2010-06-21 17:44 ` Oleg Nesterov
2010-06-21 18:00 ` Oleg Nesterov
2010-06-21 19:02 ` Roland McGrath
2010-06-21 20:06 ` Oleg Nesterov
2010-06-21 21:19 ` Eric W. Biederman
2010-06-22 14:34 ` Oleg Nesterov
2010-07-08 23:59 ` Roland McGrath
2010-07-09 0:41 ` Paul E. McKenney
2010-07-09 1:01 ` Roland McGrath
2010-07-09 16:18 ` Paul E. McKenney
2010-06-21 20:51 ` Paul E. McKenney
2010-06-21 21:22 ` Eric W. Biederman
2010-06-21 21:38 ` Paul E. McKenney
2010-06-22 21:23 ` Oleg Nesterov
2010-06-22 22:12 ` Paul E. McKenney
2010-06-23 15:24 ` Oleg Nesterov
2010-06-24 18:07 ` Paul E. McKenney
2010-06-24 18:50 ` Chris Friesen
2010-06-24 22:00 ` Oleg Nesterov
2010-06-25 0:08 ` Eric W. Biederman
2010-06-25 3:42 ` Paul E. McKenney
2010-06-25 10:08 ` Oleg Nesterov
2010-07-09 0:52 ` Roland McGrath
2010-06-24 21:14 ` Roland McGrath
2010-06-25 3:37 ` Paul E. McKenney
2010-07-09 0:41 ` Roland McGrath
2010-06-24 21:57 ` Oleg Nesterov
2010-06-25 3:41 ` Paul E. McKenney
2010-06-25 9:55 ` Oleg Nesterov
2010-06-28 23:43 ` Paul E. McKenney
2010-06-29 13:05 ` Oleg Nesterov
2010-06-29 15:34 ` Paul E. McKenney
2010-06-29 17:54 ` Oleg Nesterov
2010-06-19 5:00 ` Mandeep Baines
2010-06-19 5:35 ` Frederic Weisbecker [this message]
2010-06-19 15:44 ` Mandeep Baines
2010-06-19 19:19 ` Oleg Nesterov
2010-06-18 20:11 ` [PATCH] fix the racy check_hung_uninterruptible_tasks()->rcu_lock_break() logic Frederic Weisbecker
2010-06-18 20:38 ` Mandeep Singh Baines
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=20100619053522.GA11264@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=msb@google.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=roland@redhat.com \
--cc=stable@kernel.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.