Re: [PATCH net v3 1/2] vsock/virtio: reset connection on receiving queue overflow

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, May 15, 2026 at 11:06:42AM +0200, Stefano Garzarella wrote:
> On Fri, May 15, 2026 at 04:57:41AM -0400, Michael S. Tsirkin wrote:
> > On Fri, May 15, 2026 at 10:29:55AM +0200, Stefano Garzarella wrote:
> > > On Thu, May 14, 2026 at 01:44:53PM -0400, Michael S. Tsirkin wrote:
> > > > On Thu, May 14, 2026 at 06:45:00PM +0200, Stefano Garzarella wrote:
> > > > > On Thu, 14 May 2026 at 17:16, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> [...]
> 
> > > > > >
> > > > > >
> > > > > > And so the bag of hacks grows. I feel this is energy not well spent.
> > > > > > Please, let us fix this properly *first*. And then worry about how to
> > > > > > backport.  Maybe it will not be so terrible to backport after all.
> > > > > >
> > > > >
> > > > > TBH I don't think this is an hack, but an issue we should fix in any case.
> > > > > Regarding the second patch, I see your point, but it's a big change
> > > > > that worries me. I'd like some more time to fix it properly without
> > > > > rushing. Staying calm without realizing that userspace is broken like
> > > > > we are now without this series :-(
> > > > >
> > > > > That said, evaluating further, I think we have a similar issue also
> > > > > with STREAM on the host side where the skb usually doesn't free space,
> > > > > so we need a merge strategy also there.
> > > > >
> > > > > So, I'd like to have time to fix both definitely. If you have time and
> > > > > want to go ahead, please do.
> > > > >
> > > > > Thanks,
> > > > > Stefano
> > > >
> > > > Well my patch was a start, we just need a strategy how to avoid copying
> > > > everything, right?
> > > 
> > > Yep, and then there's the question of how to handle EOM without a payload,
> > > but I think that's a special case. In theory, we don't support sending it,
> > > but I'm not sure if POSIX allows it or not.
> > 
> > It seems to, but given we didn't allow it in the past, we probably
> > should not start now without a good solution.
> 
> Agree.
> 
> > Really we should add a feature bit for EOM to steal a byte from
> > buf_alloc. Or several bytes)
> 
> Yes, I agree. At this point, though, could we define a new protocol that
> also takes overhead into account, or would it be too complicated to
> synchronize both?

Well isn't it just X bytes per EOM? The rest can be fixed with
merging?

> > 
> > > That said, is it okay if I send a v4 of this series?
> > > 
> > > (I'm not sure if I'll be able to work on the merging next week)
> > > 
> > > Stefano
> > 
> > 
> > I do worry we are piling up hacks and we'll end up with races
> > for all our troubles. That said, up to you.
> > 
> 
> I see it differently; Patch 1 should have been there from the start.
> Patch 2, unless we completely remove the overhead, we should keep it, or use
> it to trigger merging (e.g., when the overhead reaches a threshold that
> depends on `buf_alloc`).

I'm not sure we need to merge retroactively though. Maybe just start
merging new stuff when over a threshold. Should be simpler.


> I prefer to send a v4.
> 
> Thanks,
> Stefano