lkml.org 
[lkml]   [2006]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/5] lightweight robust futexes: -V1
Ingo Molnar <mingo@elte.hu> wrote:
>
> ...
>
> E.g. in David Singleton's robust-futex-6.patch, there are 3 new syscall
> variants to sys_futex(): FUTEX_REGISTER, FUTEX_DEREGISTER and
> FUTEX_RECOVER. The kernel attaches such robust futexes to vmas (via
> vma->vm_file->f_mapping->robust_head), and at do_exit() time, all vmas
> are searched to see whether they have a robust_head set.

hm. What happened if the futex was in anonymous memory (vm_file==NULL)?

> New approach to robust futexes
> ------------------------------
>
> At the heart of this new approach there is a per-thread private list of
> robust locks that userspace is holding (maintained by glibc) - which
> userspace list is registered with the kernel via a new syscall [this
> registration happens at most once per thread lifetime]. At do_exit()
> time, the kernel checks this user-space list: are there any robust futex
> locks to be cleaned up?

Neat.

>
> ...
> The list is guaranteed to be private and per-thread, so it's lockless.
>

Why is that guaranteed?? Another thread could be scribbling on it while
the kernel is walking it?

Why use a list and not just a sparse array? (realloc() works..)

>
> There is one race possible though: since adding to and removing from the
> list is done after the futex is acquired by glibc, there is a few
> instructions window for the thread (or process) to die there, leaving
> the futex hung. To protect against this possibility, userspace (glibc)
> also maintains a simple per-thread 'list_op_pending' field, to allow the
> kernel to clean up if the thread dies after acquiring the lock, but just
> before it could have added itself to the list. Glibc sets this
> list_op_pending field before it tries to acquire the futex, and clears
> it after the list-add (or list-remove) has finished.

Oh. I'm surprised that glibc cannot just add the futex to the list prior
to acquiring it, then the exit-time code can work out whether the futex was
really taken-and-contended. Even if the kernel makes a mistake it either
won't find a futex there or it won't wake anyone up.


I think the patch breaks the build if CONFIG_FUTEX=n?

The patches are misordered - with only the first patch applied, the kernel
won't build. That's a nasty little landmine for git-bisect users.

Why do we need sys_get_robust_list(other task)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-15 22:49    [W:0.659 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site