Re: [PATCH] Re: today's futex changes

[Jamie Lokier]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/