[libvirt] [PATCH] Fix virPipeReadUntilEOF on more than 1024 bytes of data
This is a bug I found while testing the smbios support, it uses virPipeReadUntilEOF to read the stdout of the exec'ed dmidecode process and this failed to capture the full output. It read only 1024 bytes. The problem is that this is based on a poll loop, and in the loop we read at most 1024 bytes per filedescriptor, but we also note in the loop if poll indicates that the process won't output more than that on that fd by setting finished[i] = 1. The simplest way is that if we read a full buffer make sure finished[i] is still 0 because we will need another pass in the loop. Daniel diff --git a/src/util/util.c b/src/util/util.c index f7c7d32..a059675 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -984,6 +984,9 @@ virPipeReadUntilEOF(int outfd, int errfd, got = read(fds[i].fd, data, sizeof(data)); + if (got == sizeof(data)) + finished[i] = 0; + if (got == 0) { finished[i] = 1; continue; -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 11/02/2010 01:39 PM, Daniel Veillard wrote:
This is a bug I found while testing the smbios support, it uses virPipeReadUntilEOF to read the stdout of the exec'ed dmidecode process and this failed to capture the full output. It read only 1024 bytes. The problem is that this is based on a poll loop, and in the loop we read at most 1024 bytes per filedescriptor, but we also note in the loop if poll indicates that the process won't output more than that on that fd by setting finished[i] = 1. The simplest way is that if we read a full buffer make sure finished[i] is still 0 because we will need another pass in the loop.
Daniel
diff --git a/src/util/util.c b/src/util/util.c index f7c7d32..a059675 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -984,6 +984,9 @@ virPipeReadUntilEOF(int outfd, int errfd,
got = read(fds[i].fd, data, sizeof(data));
+ if (got == sizeof(data)) + finished[i] = 0; +
ACK. Worst case is a file that is exactly a multiple of 1024 now requiring one extra read to ascertain this fact, but that's not bad. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Tue, Nov 02, 2010 at 02:02:24PM -0600, Eric Blake wrote:
On 11/02/2010 01:39 PM, Daniel Veillard wrote:
This is a bug I found while testing the smbios support, it uses virPipeReadUntilEOF to read the stdout of the exec'ed dmidecode process and this failed to capture the full output. It read only 1024 bytes. The problem is that this is based on a poll loop, and in the loop we read at most 1024 bytes per filedescriptor, but we also note in the loop if poll indicates that the process won't output more than that on that fd by setting finished[i] = 1. The simplest way is that if we read a full buffer make sure finished[i] is still 0 because we will need another pass in the loop.
Daniel
diff --git a/src/util/util.c b/src/util/util.c index f7c7d32..a059675 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -984,6 +984,9 @@ virPipeReadUntilEOF(int outfd, int errfd,
got = read(fds[i].fd, data, sizeof(data));
+ if (got == sizeof(data)) + finished[i] = 0; +
ACK. Worst case is a file that is exactly a multiple of 1024 now requiring one extra read to ascertain this fact, but that's not bad.
okidoc, applied and pushed, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (2)
-
Daniel Veillard -
Eric Blake