aboutgitcodebugslistschat
path: root/tap.h
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-09-22 23:21:20 +0200
committerStefano Brivio <sbrivio@redhat.com>2023-10-04 23:27:15 +0200
commitd3192f67c492f6caa3d0779ae016c34e3d847b22 (patch)
tree4618922d3fa5f52aa0ebc9d933429ca0ee03b894 /tap.h
parentfeaeb4986c1143f39cd71cd88de6f2e5280beecc (diff)
downloadpasst-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar.gz
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar.bz2
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar.lz
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar.xz
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.tar.zst
passt-d3192f67c492f6caa3d0779ae016c34e3d847b22.zip
tcp: Force TCP_WINDOW_CLAMP before resetting STALLED flag
It looks like we need it as workaround for this situation, readily reproducible at least with a 6.5 Linux kernel, with default rmem_max and wmem_max values: - an iperf3 client on the host sends about 160 KiB, typically segmented into five frames by passt. We read this data using MSG_PEEK - the iperf3 server on the guest starts receiving - meanwhile, the host kernel advertised a zero-sized window to the sender, as expected - eventually, the guest acknowledges all the data sent so far, and we drop it from the buffer, courtesy of tcp_sock_consume(), using recv() with MSG_TRUNC - the client, however, doesn't get an updated window value, and even keepalive packets are answered with zero-window segments, until the connection is closed It looks like dropping data from a socket using MSG_TRUNC doesn't cause a recalculation of the window, which would be expected as a result of any receiving operation that invalidates data on a buffer (that is, not with MSG_PEEK). Strangely enough, setting TCP_WINDOW_CLAMP via setsockopt(), even to the previous value we clamped to, forces a recalculation of the window which is advertised to the sender. I couldn't quite confirm this issue by following all the possible code paths in the kernel, yet. If confirmed, this should be fixed in the kernel, but meanwhile this workaround looks robust to me (and it will be needed for backward compatibility anyway). Reported-by: Matej Hrica <mhrica@redhat.com> Link: https://bugs.passt.top/show_bug.cgi?id=74 Analysed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'tap.h')
0 files changed, 0 insertions, 0 deletions