Messages in this thread | | | Date | Sat, 6 Sep 2003 18:46:15 +0100 | From | Jamie Lokier <> | Subject | Re: [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/
| |