Re: [Valgrind-developers] Issue with glibc and futex system call w/ FUTEX_WAIT_BITSET

[Petar J. <mip...@gm...>]

> My only concern is whether there is a race condition here? Could the
value of the futex become equal to the value between us doing our check and
the kernel doing it's check? If it did then in principle the kernel would
then go on to read the bitset.
>
> Yes I know that won't happen in this case, but if this was a real attempt
at waiting on a lock then could it and could we miss a chance to detect an
invalid bitset?

Theoretically, if there was a race condition, it could happen, but the
intention of the syscall caller who provides different values of the futex
and the check value is to fail. I can not see a regular case than to fail.

Petar

On Fri, Jul 20, 2012 at 6:27 PM, Tom Hughes <to...@co...> wrote:

> On 19/07/12 17:08, Petar Jovanovic wrote:
>
>  It should not worry you. The trick is that the arguments are not the
>> same. The 6th argument is a "random" value (and not initialized for MIPS).
>>
>> So, in MIPS case, this is a value on stack, and the 6th argument happens
>> to be zero value. In that case, kernel will complain about bitset value
>> being all zeros.
>>
>
> Right I've looked at the kernel code now, and I understand what is
> happening and I agree in principle that your patch is right.
>
> To summarise, the game glibc is playing is to pass to the futex call a
> value (in the third argument) which it knows the futex does not currently
> have.
>
> Because FUTEX_WAIT and FUTEX_WAIT_BITSET are defined to return immediately
> without waiting (with EAGAIN) if the futex does not have the specified
> value this means that normally the call will return with EAGAIN without
> consulting the bitset.
>
> Because the bitset argument is undefined however it is also possible to
> get EINVAL if it happens to be zero, as that check is done before the value
> check.
>
> So yes, ignoring the last argument if the futex value is not equal to the
> supplied value is the correct test.
>
> My only concern is whether there is a race condition here? Could the value
> of the futex become equal to the value between us doing our check and the
> kernel doing it's check? If it did then in principle the kernel would then
> go on to read the bitset.
>
> Yes I know that won't happen in this case, but if this was a real attempt
> at waiting on a lock then could it and could we miss a chance to detect an
> invalid bitset?
>
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>