From: "Brien Oberstein" <brienpub@gmail.com>
To: "'Stefano Garzarella'" <sgarzare@redhat.com>
Cc: <netdev@vger.kernel.org>, <regressions@lists.linux.dev>,
<stable@vger.kernel.org>
Subject: RE: [REGRESSION 6.12.90 -> 6.12.94] vsock/virtio: large AF_VSOCK transfers reset under backpressure
Date: Mon, 22 Jun 2026 13:48:27 -0400 [thread overview]
Message-ID: <672f01dd026f$54fa0600$feee1200$@gmail.com> (raw)
In-Reply-To: <ajkmjgGdJp9Dj6em@sgarzare-redhat>
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.
Thanks,
Brien
-----Original Message-----
From: Stefano Garzarella <sgarzare@redhat.com>
Sent: Monday, June 22, 2026 8:22 AM
To: Brien Oberstein <brienpub@gmail.com>
Cc: netdev@vger.kernel.org; regressions@lists.linux.dev;
stable@vger.kernel.org
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
prev parent reply other threads:[~2026-06-22 17:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <467b01dd017b$733792d0$59a6b870$@gmail.com>
[not found] ` <ajkAlpiyPWmNPWfx@sgarzare-redhat>
2026-06-22 11:55 ` [REGRESSION 6.12.90 -> 6.12.94] vsock/virtio: large AF_VSOCK transfers reset under backpressure Brien Oberstein
2026-06-22 12:22 ` Stefano Garzarella
2026-06-22 17:48 ` Brien Oberstein [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='672f01dd026f$54fa0600$feee1200$@gmail.com' \
--to=brienpub@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=sgarzare@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox