lkml.org 
[lkml]   [2003]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: today's futex changes
Hugh Dickins wrote:
> The new bug is that "offset" has been declared as an alternative in
> the union, instead of as an element in the structures comprising it,
> effectively eliminating it from the key: keys match which should not.

Auch!

(Off to the post office for a pack of brown paper bags)
(And a pillow)

> The old bug is that if futex_requeue were called with identical
> key1 and key2 (sensible? tended to happen given the first bug),
> it was liable to loop for a long time holding futex_lock: guard
> against that, still respecting the semantics of futex_requeue.

That explains the hang I just saw in one run of Ulrich's test...
And it explain's why it's not repeatable.

With key1 == key2, you get to move nr_requeue waiters to the end of
the waiting list. I can't think of a good use for it, but it does do
something visible.

> + /* Make sure to stop if key1 == key2 */
> + if (head1 == head2 && head1 != next)
> + head1 = i;

Subtle, when nr_requeue > 1. That's a disturbingly nice trick :)

> While here, please let's also fix the get_futex_key VM_NONLINEAR
> case, which was returning the 1 from get_user_pages, taken as an
> error by its callers.

Yes. I just spotted it too.

> And save a few bytes and improve debuggability
> by uninlining the top-level futex_wake, futex_requeue, futex_wait.

Fair point about about debuggability, but does it really save bytes to
uninline these called-once functions?

-- Jamie
-
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: 2005-03-22 13:48    [W:0.215 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site