David Singleton <[email protected]> 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.
Andrew Morton <[email protected]> writes:
>
> +static int futex_deadlock(struct rt_mutex *lock)
> +{
> + DEFINE_WAIT(wait);
> +
> + _raw_spin_unlock(&lock->wait_lock);
> + _raw_spin_unlock(¤t->pi_lock);
And why is there a pi_lock if the code isn't supposed to support PI?
-Andi
Andi Kleen <[email protected]> wrote:
>
> Andrew Morton <[email protected]> writes:
> >
> > +static int futex_deadlock(struct rt_mutex *lock)
> > +{
> > + DEFINE_WAIT(wait);
> > +
> > + _raw_spin_unlock(&lock->wait_lock);
> > + _raw_spin_unlock(¤t->pi_lock);
>
> And why is there a pi_lock if the code isn't supposed to support PI?
>
That was a copy-n-paste from a -rt patch I happened to find. The URL David
sent was bust, and there are various things in the directory there. Maybe
we were supposed to look in a tarball, dunno.
Andrew Morton wrote:
> 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.
Andrew, I'm looking at this:
http://source.mvista.com/~dsingleton/robust-futex-1
And it doesn't seem to have a futex_deadlock function at all. In fact, its seems
to have a rather lengthy description about robust futexes and why they're a Good
Thing(TM).
What are you looking at?
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
Matan Peled <[email protected]> wrote:
>
> Andrew, I'm looking at this:
>
> http://source.mvista.com/~dsingleton/robust-futex-1
>
> And it doesn't seem to have a futex_deadlock function at all. In fact, its seems
> to have a rather lengthy description about robust futexes and why they're a Good
> Thing(TM).
>
> What are you looking at?
A file which now appears to have been deleted..
Here is an interdiff for a memory leak fix in register_futex. The
nice thing
about the slab caches are the ability to spot leaks easily.
diff -u linux-2.6.15/kernel/futex.c linux-2.6.15/kernel/futex.c
--- linux-2.6.15/kernel/futex.c
+++ linux-2.6.15/kernel/futex.c
@@ -1129,6 +1133,8 @@
if (vma->vm_file && vma->vm_file->f_mapping) {
if (vma->vm_file->f_mapping->robust_head == NULL)
init_robust_list(vma->vm_file->f_mapping,
file_futex);
+ else
+ kmem_cache_free(file_futex_cachep, file_futex);
head =
&vma->vm_file->f_mapping->robust_head->robust_list;
sem = &vma->vm_file->f_mapping->robust_head->robust_sem;
} else {
although Safari seems to always translates tabs to spaces.
David