Re: [Qemu-devel] [PATCH uq/master 2/9] event_notifier: remove event_notifier_test

[Paolo Bonzini <pbonzini@redhat.com>]

Il 12/07/2012 11:10, Avi Kivity ha scritto:
> On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
>> This is broken; since the eventfd is used in nonblocking mode there
>> is a race between reading and writing.
>>
> 
>> diff --git a/event_notifier.c b/event_notifier.c
>> index 2b210f4..c339bfe 100644
>> --- a/event_notifier.c
>> +++ b/event_notifier.c
>> @@ -51,18 +51,3 @@ int event_notifier_test_and_clear(EventNotifier *e)
>>      int r = read(e->fd, &value, sizeof(value));
>>      return r == sizeof(value);
>>  }
>> -
>> -int event_notifier_test(EventNotifier *e)
>> -{
>> -    uint64_t value;
>> -    int r = read(e->fd, &value, sizeof(value));
>> -    if (r == sizeof(value)) {
>> -        /* restore previous value. */
>> -        int s = write(e->fd, &value, sizeof(value));
>> -        /* never blocks because we use EFD_SEMAPHORE.
>> -         * If we didn't we'd get EAGAIN on overflow
>> -         * and we'd have to write code to ignore it. */
>> -        assert(s == sizeof(value));
>> -    }
>> -    return r == sizeof(value);
>> -}
> 
> I don't see the race.  Mind explaining?

The assertion can actually fire, there's nothing that prevents this from
happening:

    event_notifier_test()
        read(fd, &value, 8)
                                      write(fd, <large value>, 8)
        write(fd, &value, 8)

event_notifier_set will always write a 1 and it will take a large amount
of writes to reach overflow :) but that may not be true of other writers
using the same file descriptor.

Then, the comment is wrong in two ways.  First, we do not use
EFD_SEMAPHORE (though even if we did the only difference is that value
will be always one).  Second, we cannot write code to ignore EAGAIN,
because then we've lost the value.

With blocking I/O things would not be much better, because then
event_notifier_test() might block on the write.  That would be quite
surprising.

If we cared, we could implement the function more easily and corectly
with poll(), checking for POLLIN in the revents.  But I don't see a
sensible use case for it anyway.

Paolo