Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode

[Anthony Liguori]

Amit Shah <address@hidden> writes:

> On (Mon) 01 Apr 2013 [09:02:46], Anthony Liguori wrote:
>> Amit Shah <address@hidden> writes:
>> 
>> > Opening backends in non-blocking mode isn't necessary, we don't do
>> > anything while waiting for data.
>> >
>> > This also excuses us from checking for EAGAIN, which for the default
>> > random backend, is a very common return error type.
>> 
>> It's not common...  It really shouldn't happen however.
>
> EAGAIN is common when a file is opened in non-blocking mode.  Needs to
> be made verbose?

EAGAIN doesn't just happen randomly.  It only happens when you read from
an fd when no data is present.  Normally, that is something that is
predictable.

>> >  Starting the guest
>> > with '-device virtio-rng-pci', issuing a 'cat /dev/hwrng' in the guest
>> > while also doing 'cat /dev/random' on the host causes
>> 
>> You are essentially cat'ing the same device twice.  What's happening is
>> that there is entropy available in /dev/random so a select()
>> notification happens but before we are able to read() it, the cat of
>> /dev/hwrng ends up consuming that entropy.
>> 
>> This would never happen with a socket, for instance.  /dev/random is
>> special in there are multiple readers.
>> 
>> >
>> > backends/rng-random.c:44:entropy_available: assertion failed: (len != -1)
>> >
>> > without this fix.
>> 
>> This fix would cause QEMU to block indefinitely which I don't think is
>> very good behavior.  I think a better solution would be:
>> 
>> diff --git a/backends/rng-random.c b/backends/rng-random.c
>> index acd20af..9fde566 100644
>> --- a/backends/rng-random.c
>> +++ b/backends/rng-random.c
>> @@ -41,6 +41,9 @@ static void entropy_available(void *opaque)
>>      ssize_t len;
>>  
>>      len = read(s->fd, buffer, s->size);
>> +    if (len == -1 && errno == EINTR) {
>> +        return;
>> +    }


That's a typo.  I meant s/EINTR/EAGAIN/g

Regards,

Anthony Liguori

>
> This has to be an additional fix on top of this one.  EAGAIN has to be
> handled if we want to allow nonblocking reads, and there doesn't seem
> to be any reason to have these reads be non-blocking.
>
> OTOH, I also think we could use the glib functions for file IO, since
> handling EINTR in each open-coded read call isn't always fun.
>
>               Amit