[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Fix virPipeReadUntilEOF on more than 1024 bytes of data



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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]