]> git.ipfire.org Git - thirdparty/qemu.git/commit
Revert "chardev/char-socket: Fix TLS io channels sending too much data to the backend"
authorDaniel P. Berrangé <berrange@redhat.com>
Mon, 18 Mar 2024 13:03:19 +0000 (13:03 +0000)
committerMichael Tokarev <mjt@tls.msk.ru>
Thu, 21 Mar 2024 17:00:22 +0000 (20:00 +0300)
commitde742b16b3253bb9a194d623d0b751844bed8bc7
tree89268332289b97b4e03c90a8836ac1a4ec49d261
parent509525dc67ba2cbf39a1cecf53af84383922f966
Revert "chardev/char-socket: Fix TLS io channels sending too much data to the backend"

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>
(cherry picked from commit e8ee827ffdb86ebbd5f5213a1f78123c25a90864)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
chardev/char-socket.c