From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMfK2-00006k-Vi for qemu-devel@nongnu.org; Mon, 01 Apr 2013 10:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMfK0-0004jw-Qb for qemu-devel@nongnu.org; Mon, 01 Apr 2013 10:02:54 -0400 Received: from mail-pb0-f53.google.com ([209.85.160.53]:33564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMfK0-0004jY-IL for qemu-devel@nongnu.org; Mon, 01 Apr 2013 10:02:52 -0400 Received: by mail-pb0-f53.google.com with SMTP id un1so1203181pbc.26 for ; Mon, 01 Apr 2013 07:02:51 -0700 (PDT) From: Anthony Liguori In-Reply-To: <74d06e1f94cc2337aa1bb6784a7ad2210ec55364.1364808312.git.amit.shah@redhat.com> References: <74d06e1f94cc2337aa1bb6784a7ad2210ec55364.1364808312.git.amit.shah@redhat.com> Date: Mon, 01 Apr 2013 09:02:46 -0500 Message-ID: <87eheus60p.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu list Amit Shah 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. > 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; + } g_assert(len != -1); s->receive_func(s->opaque, buffer, len); Since this simply ignores the extraneous select notification that occurs because of the race above. Regards, Anthony Liguori > > Reported-by: yunpingzheng > Signed-off-by: Amit Shah > --- > backends/rng-random.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/backends/rng-random.c b/backends/rng-random.c > index acd20af..252139b 100644 > --- a/backends/rng-random.c > +++ b/backends/rng-random.c > @@ -74,7 +74,7 @@ static void rng_random_opened(RngBackend *b, Error **errp) > error_set(errp, QERR_INVALID_PARAMETER_VALUE, > "filename", "a valid filename"); > } else { > - s->fd = qemu_open(s->filename, O_RDONLY | O_NONBLOCK); > + s->fd = qemu_open(s->filename, O_RDONLY); > > if (s->fd == -1) { > error_set(errp, QERR_OPEN_FILE_FAILED, s->filename); > -- > 1.8.1.4