Re: [patch 0/5] lightweight robust futexes: -V1

[Ulrich Drepper <drepper@redhat.com>]

Andi Kleen wrote:
> e.g. you could add a new VMA flag that says "when one user
> of this dies unexpectedly by a signal kill all" 

"kill all"?  That is so completely different from the intended behavior.
 Robust mutexes are no concept which has been invented here.  It is
clearly specified.  The reaction to a terminating thread/process is
notification of other interested parties.

None of your proposals makes any sense in this context.


> And what happens if the patch is rejected? I don't really think you
> can force patches in this way ("do it or I break glibc")

Nothing which relies on the syscalls goes into cvs unless the kernel
side is first committed.  I never do this.  What is in cvs now is an
implementation of the intra-thread robust mutexes based on the same
mechanisms.  I.e., using the new syscall is a trivial thing since the
infrastructure is already in place.  And the method is proven to work.


> What happens when the list gets corrupted? Does the kernel go
> into an endless loop? Kernel going through arbitary user structures
> like this seems very risky to me. There are ways to do
> list walking with cycle detection, but they still have quite
> bad worst case detection times.

The list being corrupted means that the mutexes are corrupted.  In which
case the application would crash anyway.

As for the "endless loop".  You didn't read the code, it seems.  There
are two mechanisms to prevent this: the list is destroyed when the
individual elements are handled and there is an upper limit on the
number of robust mutexes which can be registered.  The limit is
ridiculously high so it'll no problem for correct programs and it also
will eliminate run-away list following code.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Attachment: signature.asc
Description: OpenPGP digital signature