Blame SOURCES/kvm-ui-track-how-much-decoded-data-we-consumed-when-doin.patch

4a2fec
From 61e62d3b4e8d0eb3715cbffcec580d5d236421a0 Mon Sep 17 00:00:00 2001
4a2fec
From: "Daniel P. Berrange" <berrange@redhat.com>
4a2fec
Date: Mon, 5 Feb 2018 11:10:02 +0100
4a2fec
Subject: [PATCH 08/20] ui: track how much decoded data we consumed when doing
4a2fec
 SASL encoding
4a2fec
MIME-Version: 1.0
4a2fec
Content-Type: text/plain; charset=UTF-8
4a2fec
Content-Transfer-Encoding: 8bit
4a2fec
4a2fec
RH-Author: Daniel P. Berrange <berrange@redhat.com>
4a2fec
Message-id: <20180205111012.6210-8-berrange@redhat.com>
4a2fec
Patchwork-id: 78877
4a2fec
O-Subject: [RHV-7.5 qemu-kvm-rhev PATCH v2 07/17] ui: track how much decoded data we consumed when doing SASL encoding
4a2fec
Bugzilla: 1527404
4a2fec
RH-Acked-by: Gerd Hoffmann <kraxel@redhat.com>
4a2fec
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
4a2fec
RH-Acked-by: Thomas Huth <thuth@redhat.com>
4a2fec
4a2fec
From: "Daniel P. Berrange" <berrange@redhat.com>
4a2fec
4a2fec
When we encode data for writing with SASL, we encode the entire pending output
4a2fec
buffer. The subsequent write, however, may not be able to send the full encoded
4a2fec
data in one go though, particularly with a slow network. So we delay setting the
4a2fec
output buffer offset back to zero until all the SASL encoded data is sent.
4a2fec
4a2fec
Between encoding the data and completing sending of the SASL encoded data,
4a2fec
however, more data might have been placed on the pending output buffer. So it
4a2fec
is not valid to set offset back to zero. Instead we must keep track of how much
4a2fec
data we consumed during encoding and subtract only that amount.
4a2fec
4a2fec
With the current bug we would be throwing away some pending data without having
4a2fec
sent it at all. By sheer luck this did not previously cause any serious problem
4a2fec
because appending data to the send buffer is always an atomic action, so we
4a2fec
only ever throw away complete RFB protocol messages. In the case of frame buffer
4a2fec
updates we'd catch up fairly quickly, so no obvious problem was visible.
4a2fec
4a2fec
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
4a2fec
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
4a2fec
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
4a2fec
Message-id: 20171218191228.31018-6-berrange@redhat.com
4a2fec
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
4a2fec
(cherry picked from commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07)
4a2fec
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
4a2fec
---
4a2fec
 ui/vnc-auth-sasl.c | 3 ++-
4a2fec
 ui/vnc-auth-sasl.h | 1 +
4a2fec
 2 files changed, 3 insertions(+), 1 deletion(-)
4a2fec
4a2fec
diff --git a/ui/vnc-auth-sasl.c b/ui/vnc-auth-sasl.c
4a2fec
index 23f2828..761493b 100644
4a2fec
--- a/ui/vnc-auth-sasl.c
4a2fec
+++ b/ui/vnc-auth-sasl.c
4a2fec
@@ -67,6 +67,7 @@ long vnc_client_write_sasl(VncState *vs)
4a2fec
         if (err != SASL_OK)
4a2fec
             return vnc_client_io_error(vs, -1, NULL);
4a2fec
 
4a2fec
+        vs->sasl.encodedRawLength = vs->output.offset;
4a2fec
         vs->sasl.encodedOffset = 0;
4a2fec
     }
4a2fec
 
4a2fec
@@ -78,7 +79,7 @@ long vnc_client_write_sasl(VncState *vs)
4a2fec
 
4a2fec
     vs->sasl.encodedOffset += ret;
4a2fec
     if (vs->sasl.encodedOffset == vs->sasl.encodedLength) {
4a2fec
-        vs->output.offset = 0;
4a2fec
+        vs->output.offset -= vs->sasl.encodedRawLength;
4a2fec
         vs->sasl.encoded = NULL;
4a2fec
         vs->sasl.encodedOffset = vs->sasl.encodedLength = 0;
4a2fec
     }
4a2fec
diff --git a/ui/vnc-auth-sasl.h b/ui/vnc-auth-sasl.h
4a2fec
index cb42745..b9d8de1 100644
4a2fec
--- a/ui/vnc-auth-sasl.h
4a2fec
+++ b/ui/vnc-auth-sasl.h
4a2fec
@@ -53,6 +53,7 @@ struct VncStateSASL {
4a2fec
      */
4a2fec
     const uint8_t *encoded;
4a2fec
     unsigned int encodedLength;
4a2fec
+    unsigned int encodedRawLength;
4a2fec
     unsigned int encodedOffset;
4a2fec
     char *username;
4a2fec
     char *mechlist;
4a2fec
-- 
4a2fec
1.8.3.1
4a2fec