All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>
Subject: [PULL 3/8] Revert "chardev/char-socket: Fix TLS io channels sending too much data to the backend"
Date: Tue, 19 Mar 2024 20:21:16 +0000	[thread overview]
Message-ID: <20240319202121.233130-4-berrange@redhat.com> (raw)
In-Reply-To: <20240319202121.233130-1-berrange@redhat.com>

This commit results in unexpected termination of the TLS connection.
When 'fd_can_read' returns 0, the code goes on to pass a zero length
buffer to qio_channel_read. The TLS impl calls into gnutls_recv()
with this zero length buffer, at which point GNUTLS returns an error
GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code
resulting in the connection being torn down by the chardev.

Simply skipping the qio_channel_read when the buffer length is zero
is also not satisfactory, as it results in a high CPU burn busy loop
massively slowing QEMU's functionality.

The proper solution is to avoid tcp_chr_read being called at all
unless the frontend is able to accept more data. This will be done
in a followup commit.

This reverts commit 462945cd22d2bcd233401ed3aa167d83a8e35b05

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 chardev/char-socket.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 2c4dffc0e6..812d7aa38a 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -496,9 +496,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque)
         s->max_size <= 0) {
         return TRUE;
     }
-    len = tcp_chr_read_poll(opaque);
-    if (len > sizeof(buf)) {
-        len = sizeof(buf);
+    len = sizeof(buf);
+    if (len > s->max_size) {
+        len = s->max_size;
     }
     size = tcp_chr_recv(chr, (void *)buf, len);
     if (size == 0 || (size == -1 && errno != EAGAIN)) {
-- 
2.43.0



  parent reply	other threads:[~2024-03-19 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19 20:21 [PULL 0/8] Misc fixes patches Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 1/8] seccomp: report EPERM instead of killing process for spawn set Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 2/8] chardev: lower priority of the HUP GSource in socket chardev Daniel P. Berrangé
2024-03-19 20:21 ` Daniel P. Berrangé [this message]
2024-03-19 20:21 ` [PULL 4/8] Revert "chardev: use a child source for qio input source" Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 5/8] crypto: factor out conversion of QAPI to gcrypt constants Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 6/8] crypto: query gcrypt for cipher availability Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 7/8] crypto: use error_abort for unexpected failures Daniel P. Berrangé
2024-03-19 20:21 ` [PULL 8/8] crypto: report which ciphers are being skipped during tests Daniel P. Berrangé
2024-03-20 15:04 ` [PULL 0/8] Misc fixes patches Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240319202121.233130-4-berrange@redhat.com \
    --to=berrange@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.