From: Oleg Nesterov <oleg@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Don Zickus <dzickus@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Jerome Marchand <jmarchan@redhat.com>,
Mandeep Singh Baines <msb@google.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 00:37:13 +0200 [thread overview]
Message-ID: <20100618223713.GA3233@redhat.com> (raw)
In-Reply-To: <20100618210801.61B4540162@magilla.sf.frob.com>
On 06/18, Roland McGrath wrote:
>
> I think you're right. I can't see what would prevent that race.
How sad.
> So for_each_process
for_each_process() looks fine. It uses init_task as the anchor,
it can't go away, it is swapper.
> and do_each_thread are safe only under
> read_lock(&tasklist_lock) and while_each_thread is only safe under
> either that or siglock.
Yes,
(Also a few places using next_thread in
> similar loops outside those macros.)
I hope that most (all?) of next_thread() users can be converted to
use while_each_thread().
> Perhaps we could move those del's from __unhash_process to
> __put_task_struct (or just delayed_put_task_struct?)
This needs write_lock_irq(tasklist), we can't take it in atomic
context. And I bet this change (at least right now) has other
implications.
> I think de_thread() in exec-by-nonleader is the only case where this
> can happen, right? So then perhaps we could make it call release_task
> only via call_rcu?
Hmm, perhaps... I am already sleeping, will try to check this idea
tomorrow. At first glance, it looks promising to me. And I see the
email from Paul which is too late to read for me today ;)
In any case, I _think_ we can fix while_each_thread(), say XXX(t)
from the previous email. But then we should audit the users like
zap_threads() which assume we should not miss any "interesting" task.
Probably zap_threads() is fine because of mmap_sem, but I can't
think properly now.
Oleg.
next prev parent reply other threads:[~2010-06-18 22:39 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 [this message]
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
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=20100618223713.GA3233@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=ebiederm@xmission.com \
--cc=fweisbec@gmail.com \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=msb@google.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.