From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN0hL-0004uB-Se for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:52:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UN0hK-0007nL-IT for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:52:23 -0400 Received: from mail-gh0-f179.google.com ([209.85.160.179]:39451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN0hK-0007nB-E4 for qemu-devel@nongnu.org; Tue, 02 Apr 2013 08:52:22 -0400 Received: by mail-gh0-f179.google.com with SMTP id z12so41823ghb.38 for ; Tue, 02 Apr 2013 05:52:21 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20130402103549.GC15084@amit.redhat.com> References: <74d06e1f94cc2337aa1bb6784a7ad2210ec55364.1364808312.git.amit.shah@redhat.com> <87eheus60p.fsf@codemonkey.ws> <20130402103549.GC15084@amit.redhat.com> Date: Tue, 02 Apr 2013 07:52:19 -0500 Message-ID: <874nfpf62k.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: > On (Mon) 01 Apr 2013 [09:02:46], Anthony Liguori wrote: >> 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. > > 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