From: Steven Rostedt <rostedt@goodmis.org>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, robustmutexes@lists.osdl.org,
dino@in.ibm.com, David Singleton <dsingleton@mvista.com>
Subject: Re: robust futex deadlock detection patch
Date: Mon, 09 Jan 2006 16:08:06 -0500 [thread overview]
Message-ID: <1136840886.6197.14.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0601092109520.18240-100000@lifa01.phys.au.dk>
On Mon, 2006-01-09 at 21:16 +0100, Esben Nielsen wrote:
> You only take the spinlocks corresponding to the current lock. What about
> the next locks in the chain? Remember those locks might not be
> futexes but a lock inside the kernel, taken in system calls. I.e. the
> robust_sem might not protect you.
> If there are n locks you need to lock n lock->wait_lock and n
> owner->task->pi_lock as you traverse the locks. That is what I tried to
> sketch in the examble below.
The thing about this is that you can't (if the kernel is not buggy)
deadlock on the kernel spin locks. As long as you protect the locks in
the futex from deadlocking you are fine. This is because you don't grab
a futex after grabbing a kernel spin lock. All kernel spin locks
__must__ be released before going back to user land, and that's where
you grab the futexes.
-- Steve
next prev parent reply other threads:[~2006-01-09 21:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 22:39 Recursion bug in -rt Dinakar Guniguntala
2005-12-15 1:03 ` david singleton
2005-12-15 19:44 ` Dinakar Guniguntala
2005-12-15 20:40 ` David Singleton
2005-12-16 0:02 ` david singleton
2005-12-16 18:42 ` Dinakar Guniguntala
2005-12-16 21:26 ` David Singleton
2005-12-19 11:56 ` Dinakar Guniguntala
2005-12-19 20:11 ` David Singleton
2005-12-15 19:00 ` David Singleton
2005-12-15 19:52 ` Dinakar Guniguntala
2005-12-20 13:19 ` Ingo Molnar
2005-12-20 15:50 ` Dinakar Guniguntala
2005-12-20 17:43 ` Esben Nielsen
2005-12-20 19:33 ` Steven Rostedt
2005-12-20 20:42 ` Esben Nielsen
2005-12-20 21:20 ` Steven Rostedt
2005-12-20 21:55 ` david singleton
2005-12-20 22:56 ` Esben Nielsen
2005-12-20 23:12 ` Steven Rostedt
2005-12-20 23:55 ` Esben Nielsen
2005-12-22 4:37 ` david singleton
2005-12-20 22:43 ` Esben Nielsen
2005-12-20 22:59 ` Steven Rostedt
2006-01-03 1:54 ` david singleton
2006-01-05 2:14 ` david singleton
2006-01-05 9:43 ` Esben Nielsen
2006-01-05 17:11 ` david singleton
2006-01-05 17:47 ` Esben Nielsen
2006-01-05 18:26 ` david singleton
2006-01-07 2:40 ` robust futex deadlock detection patch david singleton
[not found] ` <a36005b50601071145y7e2ead9an4a4ca7896f35a85e@mail.gmail.com>
2006-01-07 19:49 ` Ulrich Drepper
2006-01-09 9:23 ` Esben Nielsen
2006-01-09 20:01 ` David Singleton
2006-01-09 20:16 ` Esben Nielsen
2006-01-09 21:08 ` Steven Rostedt [this message]
2006-01-09 21:19 ` Esben Nielsen
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=1136840886.6197.14.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=dino@in.ibm.com \
--cc=dsingleton@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robustmutexes@lists.osdl.org \
--cc=simlo@phys.au.dk \
/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