Re: [REGRESSION 6.12.90 -> 6.12.94] vsock/virtio: large AF_VSOCK transfers reset under backpressure

On Mon, Jun 22, 2026 at 01:48:27PM -0400, Brien Oberstein wrote:
>Hi Stefano,
>
>Confirmed -- the 16 MB buffer fixes it: with socat owning the VSOCK-LISTEN
>and SO_VM_SOCKETS_BUFFER_MAX_SIZE/SIZE at 16 MB, a 6.12.94 guest passed
>21/21 large transfers (1.5 MB x12 through 8 MB); the same 1.5 MB payload
>failed every time without it. So the per-socket workaround covers the
>bridges whose listen I control, but not vsock services I can't
>reconfigure, which stay broken on 6.12.94.
>
>Agreed the old behaviour was buggy in its own right -- it was
>over-allocating past the advertised buffer. The practical effect for me is
>just that a config that worked on 6.12.90 no longer does on 6.12.94.
>
>A question mainly for stable@: until the merging work lands, would an
>interim be acceptable -- something that keeps ordinary small-packet
>workloads under the limit without reopening the DoS? I don't have the
>kernel-side expertise to judge what's safe there, but I'm glad to prepare
>and test whatever interim you think is right, and to test the merging
>patch when it's ready.

Let me try something: one of my patches merges the SKBs when we exceed a 
certain threshold. That should be enough to fix this issue with STREAM 
sockets. I can extract this patch from my series (which does other 
things as well) and minimize the changes so it can be backported to the 
stable branch. I’ll see if I can send you a draft later today for 
testing.

Thanks,
Stefano

>
>Thanks,
>Brien
>
>-----Original Message-----
>From: Stefano Garzarella <[email protected]>
>Sent: Monday, June 22, 2026 8:22 AM
>To: Brien Oberstein <[email protected]>
>Cc: [email protected]; [email protected];
>[email protected]
>Subject: Re: [REGRESSION 6.12.90 -> 6.12.94] vsock/virtio: large AF_VSOCK
>transfers reset under backpressure
>
>On Mon, Jun 22, 2026 at 07:55:30AM -0400, Brien Oberstein wrote:
>>Hi Stefano,
>>
>>Thanks, that matches what I'm seeing: large transfers reset mid-stream
>>instead of the sender being throttled (reliable above ~1.5 MB, fine below
>>~90 KB).
>>
>>The bind for me: it's not just this mail bridge -- I use AF_VSOCK for a few
>>host/guest services, some of which open their own sockets, so the
>per-socket
>>buffer workaround can't cover them all. That leaves pinning 6.12.90 (losing
>>the DoS fix and further kernel updates) as the only blanket option.
>
>Okay, but in that case did it work?
>
>>
>>A few quick questions:
>>
>>1. Is a -stable backport of the merging fix likely, and roughly when?
>
>We don't have a fix yet.
>
>>2. Could a smaller interim land in -stable sooner (e.g. more default
>>   headroom) without reopening the DoS?
>
>What we've merged so far is the best we can do for now, but anyone who
>wants to help improve the situation is welcome to submit patches.
>
>>3. Will the fix guarantee backpressure for any packet size, or just widen
>>   the margin?
>
>It should fix STREAM sockets for any packet size.
>SEQPACKET/DGRAM is a bit different since we need to keep boundaries, so
>it will come later if needed.
>
>>
>>Happy to test any patch
>
>THanks, I'll ask you to test.
>
>>I have a solid reproducer and can turn it around
>>in a day. I'll also file this as a tracked regression so it's not lost.
>
>Unfortunately, it's always been partially broken, using more memory than
>specified, so I don't know if this is actually a full regression, but I
>understand.
>
>Thanks,
>Stefano
>
>