aboutsummaryrefslogtreecommitdiff
path: root/hw/intc
diff options
context:
space:
mode:
authorDaniel P. Berrangé <berrange@redhat.com>2024-03-18 13:03:19 +0000
committerDaniel P. Berrangé <berrange@redhat.com>2024-03-19 20:17:12 +0000
commite8ee827ffdb86ebbd5f5213a1f78123c25a90864 (patch)
tree9ae27222375f672488de3587ec0b6cdec182f451 /hw/intc
parent8bd8b04adc9f18904f323dff085f8b4ec77915c6 (diff)
downloadqemu-e8ee827ffdb86ebbd5f5213a1f78123c25a90864.zip
qemu-e8ee827ffdb86ebbd5f5213a1f78123c25a90864.tar.gz
qemu-e8ee827ffdb86ebbd5f5213a1f78123c25a90864.tar.bz2
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>
Diffstat (limited to 'hw/intc')
0 files changed, 0 insertions, 0 deletions