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

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