From: Andrew Morton <akpm@osdl.org>
To: David Singleton <daviado@gmail.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, drepper@gmail.com,
robustmutexes@lists.osdl.org
Subject: Re: Robust futex patch for Linux 2.6.15
Date: Fri, 13 Jan 2006 13:27:04 -0800 [thread overview]
Message-ID: <20060113132704.207336d7.akpm@osdl.org> (raw)
In-Reply-To: <b324b5ad0601131316m721f959eu37b741f9e5557a2e@mail.gmail.com>
David Singleton <daviado@gmail.com> wrote:
>
> Andrew and Ingo,
>
> here is a patchthat I'd like to see tested in the mm kernel. The patch
> supports robust futexes for Linux without any RT support.
> Ulrich Drepper has been asking me for a while for a patch that just has
> robustness
> in it, no RT or PI or PQ. He'd like to see it in Linux and said he'd
> support
> it in glibc if/when it gets in.
>
> This patch was originally done by Todd Kneisel for the robust-mutex SIG
> at
> OSDL. I've fixed a few bugs and added slab support.
>
> The patch is at
>
> http://source.mvista.com/~dsingleton/patch-2.6.15-robust-futex-1
>
> There are also some simple tests for robustness in the same directory
> in robust-tests.tar.gz. These simple tests test register, deregister,
> waiting,
> timed waiting, waiting for robustness from a dieing thread to wake,
> etc.
>
Please send the patch to this mailing list with a full description, as per
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt. And by "full" I
mean something which tells us what a "robust futex" actually is (it's been
a year since I thought about them) and why we would want such a thing.
This code looks racy:
+static int futex_deadlock(struct rt_mutex *lock)
+{
+ DEFINE_WAIT(wait);
+
+ _raw_spin_unlock(&lock->wait_lock);
+ _raw_spin_unlock(¤t->pi_lock);
+
+ prepare_to_wait(&deadlocked_futex, &wait, TASK_INTERRUPTIBLE);
+ schedule();
+ finish_wait(&deadlocked_futex, &wait);
+
+ return -EDEADLK;
+}
If the spin_unlocks happened after the prepare_to_wait then it would be
more idoimatic, but without having analysed the wakeup path, I wonder if a
wakeup which occurs after the spin_unlocks and before the prepare_to_wait()
will get lost.
next parent reply other threads:[~2006-01-13 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b324b5ad0601131316m721f959eu37b741f9e5557a2e@mail.gmail.com>
2006-01-13 21:27 ` Andrew Morton [this message]
2006-01-13 22:20 ` Robust futex patch for Linux 2.6.15 Andi Kleen
2006-01-13 23:01 ` Andrew Morton
2006-01-14 16:13 ` Matan Peled
2006-01-14 20:25 ` Andrew Morton
2006-01-16 19:09 ` Re [robust-futex-2] : interdiff for memory leak fix david singleton
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=20060113132704.207336d7.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=daviado@gmail.com \
--cc=drepper@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robustmutexes@lists.osdl.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.