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

From: Hugh Dickins
Date: Mon Sep 08 2003 - 12:32:20 EST


On Mon, 8 Sep 2003, Rusty Russell wrote:
> OK, I've updated my patch on top of this. Mainly cosmetic, please
> review.
>
> Name: Minor Tweaks To Jamie Lokier's Futex Patch
> Author: Rusty Russell
> Status: Booted on 2.6.0-test4-bk9
> Depends: Misc/futex-hugh.patch.gz
>
> D: Minor changes to Jamie's excellent futex patch.
> D: 1) Remove obsolete comment above hash array decl.
> D: 2) Semantics of futex on read-only pages unclear: require write perm.
> D: 3) Clarify comment about TASK_INTERRUPTIBLE.
> D: 4) Andrew Morton says spurious wakeup is a bug. Catch it.
> D: 5) Use Jenkins hash.

Most of it (the futex_wait tweaks) looked fine to me -
though I look forward to the first report of that BUG().

Part 2, requiring VM_WRITE and removing the comment on VM_MAYSHARE,
seems a regression to me. Perhaps I misinterpreted Linus' action in
taking Jamie's patch: I took that to mean he relented a little on his
hardline position about VM_SHARED, and now accepts that in this context
VM_MAYSHARE is more appropriate (easier to document). I know I argued
that readonly futices are pointless, but I thought Jamie gave a good
picture of how a readonly view could still be used. I'd rather that
part were a separate patch, so Linus can merge or not as he wishes.

In part 5, the Jenkins hashing, I was puzzled by the "/4" in
+ (sizeof(key->both.word)+sizeof(key->both.ptr))/4,

both.ptr would be a multiple of 32 (? seems to be that way on PIII
and P4, though I gave up trying to work out quite how slab.c aligns),
and both.word would be a multiple of 1 in the shared.pgoff case, or
a multiple of PAGE_SIZE in the private.uaddr case (private.uaddr =
uaddr >> PAGE_SHIFT might make more sense). Whereas both.offset
would be a multiple of 4. I don't suppose Mr Jenkins will mind,
but I did find the "/4" puzzling in that context.

Hugh

-
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/