There's a slight problem with the current function. Assume we are
currently in a data section and we have say 42 bytes until next
section (okay, in reality sections are capped to the sector size,
but bear with me). Therefore, just before (handler) is called to
fill up the buffer with data, @want is changed to 42 to match the
amount of data left in the current section. However, after hole
is processed, we are back in data section but with incredibly
small @want size. Nobody will ever reset it back. This results in
incredible data fragmentation.

Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
---
 src/libvirt-stream.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/libvirt-stream.c b/src/libvirt-stream.c
index ed0ed7325..d7a8f5816 100644
--- a/src/libvirt-stream.c
+++ b/src/libvirt-stream.c
@@ -698,7 +698,7 @@ int virStreamSparseSendAll(virStreamPtr stream,
                            void *opaque)
 {
     char *bytes = NULL;
-    size_t want = VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX;
+    size_t bufLen = VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX;
     int ret = -1;
     unsigned long long dataLen = 0;
 
@@ -718,12 +718,13 @@ int virStreamSparseSendAll(virStreamPtr stream,
         goto cleanup;
     }
 
-    if (VIR_ALLOC_N(bytes, want) < 0)
+    if (VIR_ALLOC_N(bytes, bufLen) < 0)
         goto cleanup;
 
     for (;;) {
         int inData, got, offset = 0;
         long long sectionLen;
+        size_t want = bufLen;
         const unsigned int skipFlags = 0;
 
         if (!dataLen) {
-- 
2.13.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to