[libvirt] [PATCH] util, remote: Fixing the sending of stream when length is defined.

Michal Privoznik mprivozn at redhat.com
Mon Mar 12 09:15:38 UTC 2018


On 03/04/2018 08:24 PM, Julio Faracco wrote:
> When a length of a file is defined, the responsible thread to send
> stream is finishing inappropriately. It is happening because there is
> wrong conditional which compares an offset with the length and because
> of that the code throws ENOSPC error.
> 
> To test it:
> virsh# vol-upload ... --length N
> 
> Signed-off-by: Julio Faracco <jcfaracco at gmail.com>
> ---
>  src/remote/remote_daemon_stream.c | 24 ++++++++++++------------
>  src/util/virfdstream.c            |  5 +----
>  2 files changed, 13 insertions(+), 16 deletions(-)

So there are couple of problems here. The first one: This patch as is
(apart from points raised by Peter) makes fdstreamtest loop endlessly.
Secondly, the ENOSPC error is not transferred to the client (although it
is reported in the logs):

  # virsh vol-upload --length 1000 --pool default --vol vol.img --file /dev/random
  error: cannot close volume fd.img
  error: Library function returned error but did not set virError

For this I have a patch and I'll send it soon. But the root cause is
that client indeed sends more data than announced in --length (thank God
for the wireshark dissector plugin). So server replies with ENOSPC.
However, this always used to be the case even before I touched that part
of code. So I think the proper fix is to close the stream at daemon side
once fdst->offset reaches fdst->length.

My recollection is that back in days of iohelper we had a pipe where we
just pushed incoming data to and iohelper pulled it and wrote it into
the file. However, as soon as it reached fdst->length limit it died
which caused stream to get closed.

Michal




More information about the libvir-list mailing list