Message ID | 20180112125854.18261-13-kraxel@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 12 January 2018 at 12:58, Gerd Hoffmann <kraxel@redhat.com> wrote: > From: "Daniel P. Berrange" <berrange@redhat.com> Hi Dan: just FYI: > The previous patches fix problems with throttling of forced framebuffer updates > and audio data capture that would cause the QEMU output buffer size to grow > without bound. Those fixes are graceful in that once the client catches up with > reading data from the server, everything continues operating normally. 12345678901234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 Your wrap settings on your editor for git commit messages seem to be a bit mis-set -- wrapping around 72 cols or so is recommended. I've applied the pullreq but noticed in passing that git log wraps a bit awkwardly on an 80-column xterm. thanks -- PMM
On Fri, Jan 12, 2018 at 04:40:32PM +0000, Peter Maydell wrote: > On 12 January 2018 at 12:58, Gerd Hoffmann <kraxel@redhat.com> wrote: > > From: "Daniel P. Berrange" <berrange@redhat.com> > > Hi Dan: just FYI: > > > The previous patches fix problems with throttling of forced framebuffer updates > > and audio data capture that would cause the QEMU output buffer size to grow > > without bound. Those fixes are graceful in that once the client catches up with > > reading data from the server, everything continues operating normally. > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > 1 2 3 4 5 6 7 8 > > Your wrap settings on your editor for git commit messages seem to be a > bit mis-set -- wrapping around 72 cols or so is recommended. > > I've applied the pullreq but noticed in passing that git log wraps > a bit awkwardly on an 80-column xterm. Thanks, I'll see about fixing that Regards, Daniel
diff --git a/ui/vnc.c b/ui/vnc.c index 4805ac41d0..e53e84587a 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -1521,8 +1521,37 @@ gboolean vnc_client_io(QIOChannel *ioc G_GNUC_UNUSED, } +/* + * Scale factor to apply to vs->throttle_output_offset when checking for + * hard limit. Worst case normal usage could be x2, if we have a complete + * incremental update and complete forced update in the output buffer. + * So x3 should be good enough, but we pick x5 to be conservative and thus + * (hopefully) never trigger incorrectly. + */ +#define VNC_THROTTLE_OUTPUT_LIMIT_SCALE 5 + void vnc_write(VncState *vs, const void *data, size_t len) { + if (vs->disconnecting) { + return; + } + /* Protection against malicious client/guest to prevent our output + * buffer growing without bound if client stops reading data. This + * should rarely trigger, because we have earlier throttling code + * which stops issuing framebuffer updates and drops audio data + * if the throttle_output_offset value is exceeded. So we only reach + * this higher level if a huge number of pseudo-encodings get + * triggered while data can't be sent on the socket. + * + * NB throttle_output_offset can be zero during early protocol + * handshake, or from the job thread's VncState clone + */ + if (vs->throttle_output_offset != 0 && + vs->output.offset > (vs->throttle_output_offset * + VNC_THROTTLE_OUTPUT_LIMIT_SCALE)) { + vnc_disconnect_start(vs); + return; + } buffer_reserve(&vs->output, len); if (vs->ioc != NULL && buffer_empty(&vs->output)) {