From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794493883; b=wRc1kDlPUr1090oNZkONwNMGG2mPu10JJ9UK9ffzRYSW+msYQmZ731vECLm35Vwi8gp8 bkcieMVxL/O+ur31MvZlqIg8yyF1HsiON5OKcEOkLb2sv92P/YiB7EgbVUKm2BJkN8HHs 1oYJeRX1wlrMYFpuo6FCICco7tYkc58p4iZb1IJOpxbHyZqxjtHllN9BRmxYd715sOOHA 7iZ5PNh7IsQDEymnVgSviiE6OXtSPLR+4yWomjUnbTusxvyw6F0MZJE8Q2mhGa/qye74F nd1acD88+sDPIXoC4G+fI3X78+0m3A1hh3/x4wXyuD5o8iHpieKy3KplSVTIx+GUkAA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794493883; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=Vth6PCbpSm/10fRmDbxR+C2gNDjvG6s3yrcjNyPLdBg=; b=TuoostGi+o8eEKONoIGUesUfLc8gkwRhQdMcV4M3Fc/6A2mZcRQ1gQpCxlr0Xu1J6MYv 5+gQukeXUrB/yciZaKFVMEjnDU4pwmvMB4CKtl74IPX3TXgNjLfT2IwezvLHjmO6vZnuv wsVB+ayOEoNX1jx6mdc8MpRSFZkKBXdFzA7jmkgVIFDrmKKNbd1NUXK2GaA391sd+j9Xw ZNkFvI9u8S6ySeUtxNVEduPNkjoTTBIuUhfUUU7r3M9RBb7k5h/04itSjZzR7ca4X1+Jw TRx/f3A008cwZLixQGkyt6X6Ikz2G0RyWxws5vYjiUofyLC+dCiG3Dw/g0eH/qSLOxg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Q8ue6ETW; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=Ps8mnj6y; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 47825606D543 for ; Thu, 12 Nov 2026 14:31:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 47825606D543 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Q8ue6ETW; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=Ps8mnj6y DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1794493881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vth6PCbpSm/10fRmDbxR+C2gNDjvG6s3yrcjNyPLdBg=; b=Q8ue6ETWbJ6EHIXuOhEymwc7jFdunQLU3ORUnC1kqMBJDwBpNVgyrUMjwAlI992ljqyUC8 gLtkkwONluJXJB+qcn/u0wc99fya5SiRqWwsQOFytwLsy0PV+1h79q845ZdC8P4wqlvdUk n4MD1bKkFMO+O8kgCsFsUFnP8WSm75k= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-110-V5jhGVxcOgOx0-ybGdkCqA-1; Thu, 12 Nov 2026 09:31:19 -0500 X-MC-Unique: V5jhGVxcOgOx0-ybGdkCqA-1 X-Mimecast-MFC-AGG-ID: V5jhGVxcOgOx0-ybGdkCqA_1794493878 Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-84fe2593525so5608605a34.3 for ; Thu, 12 Nov 2026 06:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1794493878; x=1795098678; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Vth6PCbpSm/10fRmDbxR+C2gNDjvG6s3yrcjNyPLdBg=; b=Ps8mnj6y/K5578klqSeu5p96RlsZH+KiVA3Zsjn8QskaSj8YPuIk8lkfT+BO1zxtky JlujZHDZ91+6rIf3WfwCGuAUX3F/4fQZsKP1L0o1Ro6gLlTdw2X19z7tovPZD/UF331J A+Gyxe09t41ajG+VxGSB647Yfc06d+Qa70mABGfM7U4umWA2CgLv8MLlJ8OYr5Nd2lTj ax39p0D+iWp2nBTcecSIakOQFkK9OIdhnxJ3C3X+Hu3eXygiDCWUYuvNJtSebBQcd3nA mA3M9cg32UDx7nZ/+vo7AsT/F7E/BjEAF42Hb6cAkHSo8JkCu5dn4bjPsCFd6P1IcE0S 50Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794493878; x=1795098678; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Vth6PCbpSm/10fRmDbxR+C2gNDjvG6s3yrcjNyPLdBg=; b=TUrzbzhp66bOEcs1ZQCozkK6HvpkjgT97mCS6KgS2UdzIjhWOpOlu3sO+wmyBr1Ggz zXjPumdZDsssMA74PJMK90uBuI1EmBuVOMcD4NQe65L3NWxMCy6nAbGLPvK4Tw+J00tg yUJRZ1mWSrXenPDmSU7Wazd9bAaj72j0li2iGCuafzNO+PhUp7XfAaFGImCns7kFsI9u HIu4gGtQCAGWachdkp4mpHgngJN+FUtfV7j4c1+lL678puxesiDZ/DEllW4MYfiW0d9N jNMoyjFijXN7d88GO/IdTMmfsXW9JdiQdHQ/t0oGLMmh1ekeJygWsSzE7hq+0znFbQAR ewZg== X-Forwarded-Encrypted: i=1; AL+hErGk8YdQRNhGVd4UD+94011BL+e5n8NMsC73IgYRk7lzamuXCI7BFGnbqGPPwwzj1w3RbcPuh8w=@vger.kernel.org X-Gm-Message-State: APuU4Z/8eFTlyjbpySiExB8m4rpEFjSZtDI2pzh8o6gtYfu+koL74eCw KqGduFfT6QWtuU1P2WlbqVHD3EB1NSA07WxA5bRAnPehZhelXucZ56oQmfDjOpePtJccpmZdq25 zDdifChcklypBBDKhlQiQGt5sPthf/Z3aD2rjVk2FvikBOkBNVlAJgbo6fA== X-Gm-Gg: AYBFou2lu1Zi3dKtBRI0rGzcOeHfupudlPkhLBNAkqHO7leT2Lg5GeIK6ulICKLkCTw SuEtnXoKa7TRbKzaGszTVorjkwn0NFhifvFjpKnb4wI7LFObb11VJZU772P6rdhw5c2Ng8e4mzn 9gS3Zie7+09sTZCAMulq5tMotY/5LH36K5WYs9a5hr+tP/K/qziQ0OzM91Hdx5kvj76zCuDGWpW tFxUyLNJh+KkoyZS28XWDJZLyf61DRBgUqWWCEkGhihXv0yYO/0WSPc4aMpHx5nhWpwvUoCwxZB 0ER+lE4UsYKWWuIc3Y2VF3/KIrD+1v2SIGkL/Knn7UAtjdB0Qf35MFqK6qDW04sqxZGI2DopbKu MqSnW9PM9xdAZ2yuErY8V/6dUU/qbMdiRtkbsgmWj709Jq5qgE+n5 X-Received: by 2002:a05:6808:30a4:b0:4e5:c2b4:33a4 with SMTP id 5614622812f47-56b980309bdmr5402619b6e.50.1794493878283; Thu, 12 Nov 2026 06:31:18 -0800 (PST) X-Received: by 2002:a05:6808:30a4:b0:4e5:c2b4:33a4 with SMTP id 5614622812f47-56b980309bdmr5402575b6e.50.1794493877673; Thu, 12 Nov 2026 06:31:17 -0800 (PST) Received: from sgarzare-redhat ([69.196.88.181]) by smtp.gmail.com with ESMTPSA id 5614622812f47-56e24b33665sm42678b6e.13.2026.11.12.06.31.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2026 06:31:16 -0800 (PST) Date: Thu, 12 Nov 2026 15:31:01 +0100 From: Stefano Garzarella To: Oleg Drokin Cc: stefanha@redhat.com, mst@redhat.com, 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: Re: [PATCH net v2 2/3] vsock/virtio: bound the send credit by bytes not yet consumed by the transport Message-ID: References: <20261106050244.602625-1-green@linuxhacker.ru> <20261106050244.602625-3-green@linuxhacker.ru> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20261106050244.602625-3-green@linuxhacker.ru> On Fri, Nov 06, 2026 at 12:02:43AM -0500, Oleg Drokin wrote: >The send credit is > > min(peer_buf_alloc, buf_alloc) - (tx_cnt - peer_fwd_cnt) > >where peer_fwd_cnt is taken unchecked from every header the peer sends. >A peer that never consumes what it is sent but keeps reporting >fwd_cnt == tx_cnt gets unlimited credit: every send() is accepted and >the skbs pile up in the transport's queue (on a host, vhost's >send_pkt_queue, for a guest that posts no rx buffers). The skbs are >GFP_KERNEL allocations charged to no memory cgroup. The peer learns >tx_cnt easily when the host side relays a stream it also controls. > >Commit 8ee784fdf006 ("vsock/virtio: cap TX credit to local buffer size") >bounded peer_buf_alloc, but not peer_fwd_cnt. > >bytes_unsent (maintained for SIOCOUTQ) counts what was handed to the >transport and not yet consumed by the device. It is local knowledge, so >bounding it by the same window limits a lying peer to one window of >queued data per socket. > >For an honest peer, bytes_unsent can exceed tx_cnt - peer_fwd_cnt only >by data the peer already has but the transport has not yet released: > > - on a host, the delivered part of an skb that vhost splits across rx > buffers smaller than the skb: the peer acknowledges the pieces, but > bytes_unsent drops only once the whole skb is delivered, so at most > one skb (64 KiB); > - in a guest, tx buffers the host has consumed but > virtio_transport_tx_work() has not reaped yet: vhost passes the > packet to the host socket before it marks the buffer used, so the > host's credit update can arrive first. > >Either way the window shrinks only until the transport catches up; >nothing stalls and nothing changes on the wire. The writer is woken by >sock_wfree() once enough of the queued skbs are freed, as it already is >when credit comes back. > >With a user-space vhost-vsock "guest" that posts no rx buffers and >acknowledges everything, one host socket queued 256 MiB in under 2 s >(SIOCOUTQ 268304384, where the test stops); with this patch it stays at >one window (SIOCOUTQ 262144). > >Found by an LLM-assisted security review of vhost-vsock, done while >porting a project from Xen to KVM, and reproduced as above. > >Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") >Signed-off-by: Oleg Drokin >--- > net/vmw_vsock/virtio_transport_common.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >index 1e762a480df4..74a8fdf825d5 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -1031,14 +1031,17 @@ EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_has_data); > > static s64 virtio_transport_has_space(struct virtio_vsock_sock *vvs) > { >+ s64 tx_buf_size = virtio_transport_tx_buf_size(vvs); > s64 bytes; > > /* Use s64 arithmetic so if the peer shrinks peer_buf_alloc while > * we have bytes in flight (tx_cnt - peer_fwd_cnt), the subtraction > * does not underflow. > */ >- bytes = (s64)virtio_transport_tx_buf_size(vvs) - >- (vvs->tx_cnt - vvs->peer_fwd_cnt); >+ bytes = tx_buf_size - (vvs->tx_cnt - vvs->peer_fwd_cnt); >+ >+ /* peer_fwd_cnt is peer-controlled, bytes_unsent is not. */ Would be nice to explain a bit better what we are preventing here. Not a long description, just few words. >+ bytes = min_t(s64, bytes, tx_buf_size - (s64)vvs->bytes_unsent); TBH I found this code a bit unreadable, what about this: in_flight = max_t(s64, vvs->tx_cnt - vvs->peer_fwd_cnt, vvs->bytes_unsent); bytes = (s64)virtio_transport_tx_buf_size(vvs) - in_flight; Thanks, Stefano > if (bytes < 0) > bytes = 0; > >-- >2.56.0 >