All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@linuxhacker.ru>
To: sgarzare@redhat.com, stefanha@redhat.com, mst@redhat.com
Cc: jasowangio@gmail.com, eperezma@redhat.com,
	xuanzhuo@linux.alibaba.com, bobbyeshleman@meta.com,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org,
	virtualization@lists.linux.dev, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH net 0/3] vsock/virtio: bound what a peer can make the host queue
Date: Wed,  4 Nov 2026 19:01:38 -0500	[thread overview]
Message-ID: <20261105000141.3617241-1-green@linuxhacker.ru> (raw)

A virtio-vsock peer that does not consume what it is sent can make the
local side queue memory that no limit covers. On a host the peer is a
guest, and the memory is GFP_KERNEL, charged to no memory cgroup. Two
ways remain on net/main:

 - the send credit trusts the fwd_cnt the peer reports, so a peer that
   never reads but keeps acknowledging gets unlimited credit (patch 2);
 - credit updates are not bounded at all: a peer can solicit them with
   OP_CREDIT_REQUEST, or by sending small packets that a reader drains,
   while posting no rx buffers (patch 3).

Patch 1 fixes the accounting of packets that vhost drops on rx errors;
patch 2 relies on bytes_unsent being right.

Nothing changes on the wire.

Tested in an x86_64 qemu/KVM guest running the kernel under test
(net/main 03897066069f); the "guest" is a user-space program driving
/dev/vhost-vsock directly, talking to plain AF_VSOCK host sockets:

  case                                      net/main      this series
  lying fwd_cnt, no rx buffers, 2 s of      256 MiB       256 KiB
  non-blocking send() on one socket         queued        (one window)
  20000 OP_CREDIT_REQUEST, no rx buffers    +18.5 MiB     +0
  20000 1-byte packets, each read by host   +18.0 MiB     +24 KiB

vsock_test from tools/testing/vsock passes over loopback and between a
nested guest and its host. A bidirectional stress test (up to 512
connections streaming both ways, readers draining in small reads) runs
without stalls, and vsock_perf throughput stays within run-to-run noise.
With KASAN and lockdep enabled, these tests show no reports.

The reproducer (a small user-space program that drives /dev/vhost-vsock
as the guest) is available on request.

The patches, the test setup and these changelogs were prepared with an
AI coding assistant (Claude); the tests above were run as described.

Oleg Drokin (3):
  vhost/vsock: release the accounting of packets dropped on rx errors
  vsock/virtio: bound the send credit by bytes not yet consumed by the
    transport
  vsock/virtio: queue at most one credit update per socket

 drivers/vhost/vsock.c                   | 25 +++++++--
 include/linux/virtio_vsock.h            |  5 ++
 net/vmw_vsock/virtio_transport.c        |  2 +
 net/vmw_vsock/virtio_transport_common.c | 69 +++++++++++++++++++++++--
 net/vmw_vsock/vsock_loopback.c          |  1 +
 5 files changed, 95 insertions(+), 7 deletions(-)

-- 
2.56.0


             reply	other threads:[~2026-11-05  0:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  0:01 Oleg Drokin [this message]
2026-11-05  0:01 ` [PATCH net 1/3] vhost/vsock: release the accounting of packets dropped on rx errors Oleg Drokin
2026-11-06  0:02   ` sashiko-bot
2026-11-05  0:01 ` [PATCH net 2/3] vsock/virtio: bound the send credit by bytes not yet consumed by the transport Oleg Drokin
2026-11-06  0:02   ` sashiko-bot
2026-11-05  0:01 ` [PATCH net 3/3] vsock/virtio: queue at most one credit update per socket Oleg Drokin
2026-11-06  0:02   ` sashiko-bot
2026-11-06  0:19   ` Michael S. Tsirkin
2026-11-06  5:02     ` Oleg Drokin
2026-11-05  0:03 ` [PATCH net 0/3] vsock/virtio: bound what a peer can make the host queue netdev-bot+sinfo
2026-11-05  0:19   ` Oleg Drokin

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=20261105000141.3617241-1-green@linuxhacker.ru \
    --to=green@linuxhacker.ru \
    --cc=bobbyeshleman@meta.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=horms@kernel.org \
    --cc=jasowangio@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.