From nobody Fri Jun 12 18:34:38 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F93E3C3BE6 for ; Wed, 13 May 2026 10:54:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778669673; cv=none; b=lgFEbTxIpIMyn8yjPWbOKcTxL3bnOOdu4ri5nfKASkx8oQvM5/MkvaQn8kHN9Ta/O0urMgC1eQmiQ/q7pDlzg6rQll6TytAPDO5jDpF7mh1xD3ZpngMS16UHwitZohiRC/8CE2euH5fnQudcqxtLmllyEqQadNv3vI/5HYrWzjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778669673; c=relaxed/simple; bh=ttq2nGPLIE/1il8H5a57hLhcGZjBjCwtRxosBU4xsEM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QYN8M0dhqYr+zhbHt5h2PAXD3F14QawGKqvws0TLctWRK0WN9jys5k1ZkAoMBrhrDAaSTZeJDfVJELklKngIeYWA4B623Xi/72U4WkuU7CYoysxaZ6OdwZuHcpKCK6TFKHtzIQBo1L54v92rvz/rVdUkD/U4MUAREYsk7sRqKus= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ud1+8sjU; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=K02HUe/r; arc=none smtp.client-ip=170.10.129.124 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.b="Ud1+8sjU"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="K02HUe/r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778669669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PAFSeIkpvfQYT7wQ2CerCQBM43nlr6dVNS3iNHBRyXI=; b=Ud1+8sjUbcrIvoooo+Y3ZgevTHIGjElv/dQ7RmiBAFFm6gzyMDKQaXCN6Kb2eTNlIiqy/E wjGaNLL/BPyK1AkLCLGHYAM2dJFbNp9MMsIQeYuQhTwl/7fbWLnz43+piNxUj28UAD/lWK 3whU0Q37LfY1g15XgTLgfgyGetrvEms= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-457-PhkjRKD6M9GFA-_EzUR1ew-1; Wed, 13 May 2026 06:54:27 -0400 X-MC-Unique: PhkjRKD6M9GFA-_EzUR1ew-1 X-Mimecast-MFC-AGG-ID: PhkjRKD6M9GFA-_EzUR1ew_1778669667 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48e6af7a9cdso35481905e9.3 for ; Wed, 13 May 2026 03:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778669666; x=1779274466; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PAFSeIkpvfQYT7wQ2CerCQBM43nlr6dVNS3iNHBRyXI=; b=K02HUe/rsMpD/tQD06xhMtM7KoVrVMTQng7xwzABJNvIYhfV7UCCgzvH1z2leR0xNg fvPGRdDxbvXm0aHtapEcC5ghAATaYmeVwsnew3WYRyyeJBmtUjVFER3cui4KTaMoxmWS JgJDnHXoTA5a61GKJdp/Q5tUQjjYSBTnjHUiOHfHEG+Aef3iN5S0jAmXHBE7O9MJwl4j QAZl1jeDDcy80A50Ri3D8ziCx41LR0eZqNwypX+qV7660Re1kzRkbZsfM450eSM5f4sJ gLTOq6+piexZxApPH8fFXGQEdREGJctitviFYyG/0fpLmkrc9qQeJGlc92U3KzwDgh+u siaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778669666; x=1779274466; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PAFSeIkpvfQYT7wQ2CerCQBM43nlr6dVNS3iNHBRyXI=; b=XzIM+N1NMJDPmIExBo2jtsi3hUPEzAamsF4meqyf8ZJ5DU7se5zP0qfGVP/aFBLMk2 ZpV4FWvaCovmeYjcez2pmNWLq78pWd/dh6CQLixlWdIhR4Qmhkh1QdMC2qV5j43d5mTU VbtRs7Y5dP7uJT2+nWd3jbRABo6z5UxR1b+2eL/pbZSP+aMlFcrQQ2l7yHCg2bBrRxqH +osaS8B/dkHijrEdadnrJKlR5QqZ4oXWwJmCQah0m/vbP3tc/PvryFjujS8GAXCMs8Zy aBn0xKDLELoOq01JteAkaJkY1IkhqCxR4VepZsEGujS42VOIcb3T1KBESUUGQcabME+X 2PfA== X-Forwarded-Encrypted: i=1; AFNElJ9vr6VsEIK8Rn51jIJD97+s9ZTy3adjyzw/JuKrss7mUH7iq2YdjJ25j8v7Y31i0g0qKAnmlyCPhIu40LQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwZFB/xv2IUhq7w5JYx6RHcUBCHL2otlKmZpiPWNhxZGwf+5q+p JPemWePoK9pOrfo8CclP0irque7D2bucghS9mPc//62peGvTArSHHbgm5yaM1QyUBfJuQKCyDpH CxbNfDGtfqQ3KiU/UzLHjS4ETQsnWolekbzXtKv5ycyNleAveYIVVIADCH9BeHrKnTQ== X-Gm-Gg: Acq92OGZP4oJBtZ29i55BTi8TA2Odyw+IDRA9/qt30eBrLcYcB7k0ez9162OzVRETCr Bucn9kzabboHJOkqecCvakqsr13f8sWOwp+SlK4qyGwzdN5AqaA5KwCU3Sl34MaPpFaWNFhJRx1 gnddUANqBK1E9fDCtBe6Wc8GKUFJXI3Pd/rkRIFxyBJVD/ppuaLKVpEOXVfDcm/wkL8aynEIgCL c3WVZjYeWO+b3SZ9qdEYVAwDbSbbI3F59RwbFgNNi2NM2Skt+Jj+KfBXXwHSQh6HzBuvOnCJVjA uBCm00SSTw46shoIlGisWz7Hd/X1UYieYYohLRgMf/LnXrGJ/4p9S7tGOdLs0hM4rYnNINsNR2G UUFS79OJbeu5l+zamoPk/6YbB0cblonWWeeFvSJx4qiXlqeNqOzZYs+LQ63GO X-Received: by 2002:a05:600c:4f54:b0:488:ab1d:dcc5 with SMTP id 5b1f17b1804b1-48fc9a4b276mr40460175e9.27.1778669666578; Wed, 13 May 2026 03:54:26 -0700 (PDT) X-Received: by 2002:a05:600c:4f54:b0:488:ab1d:dcc5 with SMTP id 5b1f17b1804b1-48fc9a4b276mr40459645e9.27.1778669666028; Wed, 13 May 2026 03:54:26 -0700 (PDT) Received: from stex1 (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fc8d27d31sm106419235e9.8.2026.05.13.03.54.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 03:54:24 -0700 (PDT) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Xuan Zhuo , "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , linux-kernel@vger.kernel.org, Simon Horman , Paolo Abeni , Jakub Kicinski , Stefano Garzarella , Jason Wang , kvm@vger.kernel.org, Stefan Hajnoczi , virtualization@lists.linux.dev, Eric Dumazet , "David S. Miller" Subject: [PATCH net v3 1/2] vsock/virtio: reset connection on receiving queue overflow Date: Wed, 13 May 2026 12:54:16 +0200 Message-ID: <20260513105417.56761-2-sgarzare@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260513105417.56761-1-sgarzare@redhat.com> References: <20260513105417.56761-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stefano Garzarella When there is no more space to queue an incoming packet, the packet is silently dropped. This causes data loss without any notification to either peer, since there is no retransmission. Under normal circumstances, this should never happen. However, it could happen if the other peer doesn't respect the credit, or if the skb overhead, which we recently began to take into account with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), is too high. Fix this by resetting the connection and setting the local socket error to ENOBUFS when virtio_transport_recv_enqueue() can no longer queue a packet, so both peers are explicitly notified of the failure rather than silently losing data. Fixes: ae6fcfbf5f03 ("vsock/virtio: discard packets if credit is not respec= ted") Signed-off-by: Stefano Garzarella --- net/vmw_vsock/virtio_transport_common.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 989cc252d3d3..4a4ac69d1ad1 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1350,7 +1350,7 @@ virtio_transport_recv_connecting(struct sock *sk, return err; } =20 -static void +static bool virtio_transport_recv_enqueue(struct vsock_sock *vsk, struct sk_buff *skb) { @@ -1365,10 +1365,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_lock_bh(&vvs->rx_lock); =20 can_enqueue =3D virtio_transport_inc_rx_pkt(vvs, len); - if (!can_enqueue) { - free_pkt =3D true; + if (!can_enqueue) goto out; - } =20 if (le32_to_cpu(hdr->flags) & VIRTIO_VSOCK_SEQ_EOM) vvs->msg_count++; @@ -1408,6 +1406,8 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_unlock_bh(&vvs->rx_lock); if (free_pkt) kfree_skb(skb); + + return can_enqueue; } =20 static int @@ -1420,7 +1420,16 @@ virtio_transport_recv_connected(struct sock *sk, =20 switch (le16_to_cpu(hdr->op)) { case VIRTIO_VSOCK_OP_RW: - virtio_transport_recv_enqueue(vsk, skb); + if (!virtio_transport_recv_enqueue(vsk, skb)) { + /* There is no more space to queue the packet, so let's + * close the connection; otherwise, we'll lose data. + */ + (void)virtio_transport_reset(vsk, skb); + sk->sk_state =3D TCP_CLOSE; + sk->sk_err =3D ENOBUFS; + sk_error_report(sk); + break; + } vsock_data_ready(sk); return err; case VIRTIO_VSOCK_OP_CREDIT_REQUEST: --=20 2.54.0 From nobody Fri Jun 12 18:34:38 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C458310762 for ; Wed, 13 May 2026 10:54:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778669676; cv=none; b=AdQJZYXzpsCfNK4qu/iM+vhGkNiEDSX0vv9S7NSCbgqPwWcmdcwBdJIIrXdc08Kmx7dV5kDBKDrLV4OL/Ze61faJ4yZy/6ebGsh7hj5+KfhO09b8zWH5DfnyaZ4p35vnuZp/W/kSgt9XKyyqUA74SNPn+Mox88RmhEFR8+VMJwI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778669676; c=relaxed/simple; bh=IvdEZvwln3zcfx+cvlKQindvsy3EmR5EckwkcdVQXFY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GHpWrcA4Si2FNxoI2u30T3ScH6WjgA/ElGR198VEOJ7LTPjOuOOLDRzvdCQO9Katb2tofw4WVEyAF2vE9BV2VxZLEqzClYhHJFFXNekfhOoyYZ/M+gqeQgkJCB4cDSFxq+6C/ERehDqSb4OnWJT+b8ce8ezrU8GrzSYYrST2EoQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=VXcAco1F; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=juwA71bu; arc=none smtp.client-ip=170.10.129.124 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.b="VXcAco1F"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="juwA71bu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778669673; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aGSDbvLykcv2buTIXBcK0yd8xK4cY9P0ZJuiRfh0cTI=; b=VXcAco1FPQATQIBfMJUIYOUU0DKWvk/VXKWjBHqPkTiLZwhqZWI/1+E6U5d8TenW3GszP+ cxK/m+e1fDrStXaoLR9JwFkewqLASsQLXJ8F8u7KGNsqTG6AuefQhuDDeIyH+akGgEcg0g L8370jTIbbtc+hUsiPT7rkpGjPEekx4= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-507-xKe9ekDMOCeCtTW2m3J5VA-1; Wed, 13 May 2026 06:54:32 -0400 X-MC-Unique: xKe9ekDMOCeCtTW2m3J5VA-1 X-Mimecast-MFC-AGG-ID: xKe9ekDMOCeCtTW2m3J5VA_1778669671 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-43d7a5b9678so4375097f8f.2 for ; Wed, 13 May 2026 03:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778669671; x=1779274471; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aGSDbvLykcv2buTIXBcK0yd8xK4cY9P0ZJuiRfh0cTI=; b=juwA71bu3+DpWVxkvtaiE8MriHnjhdawBICKnY8HPizQRezQBhtVv40XfPXy8NrZ/b 2EQZtv5O8frk3ZtOqBqC/KPEa+TiW5OPpqpFPRzhaUGTj6VS4NtN7pedKVzJUlFWZI6q GYayXwyqIN3Ll062TTyrHI7K39rmaWS37KK6m4WgRjWv6yTyZIMGVRtHolI1j1xAjUD0 rEQw4hqIjShs3YjNGoUZ5PzPRKLT5yVU4GFaId5CGi1VnaUUFklq5QFPUa7EVLgc+uB0 3BingDRsYYl3AFV+zLmhdUi936ixDnhgMcJx049m0eT+cEJg/mzCKUi05pRgkhsNzJz/ tP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778669671; x=1779274471; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aGSDbvLykcv2buTIXBcK0yd8xK4cY9P0ZJuiRfh0cTI=; b=nMfIq0MvWPvttFRhbA7daLyPft5mG4EOFaUlR5K3ONmPH09RbxW/90p1dJGR1BjdKL 7Uub1r2tccefi4lMP7PYcwzLcUV4eLJmzLEM9B8jcMY2LCpTsoA73oynn/juKiP8Qvrb 9DIbuhtDIZ/TCRcwG+mU4EujZEZuT7aobbXfc6LdiYiah0Ub6eSLlxn5dk5uD+7mjqrk RKDL7Xfj68+v+9xyHAU1kMt+ksHaNjBwoFGGKH7h5ra+RyUGfH/tO4K0nHVwRhIq2wb+ qwBlTpBgOx0KBXk1eohyjUxKTTteUCJZI7UUY6Pr7wOexoTjJuIBVhz8+tj+hU/oPYIf f+8A== X-Forwarded-Encrypted: i=1; AFNElJ8khDkd3VccGwoMj/Te0gnFLQ6APrb21I8TZBhHZdzqH4hwz8f0GTBHczesMdgYqJ8y/z3spqRIHB/dknM=@vger.kernel.org X-Gm-Message-State: AOJu0YzgwJaz2orlMnRYsZ1kXoZoTnUFmn2/SnMG37gPt03QsfnTAiDD umdLSFcZVXdkpps4lUq5u3kuGJY+r31Aemj050b36Gdz8yKVcTJAEh2Xzkr1wHlnZYGMJaE8ZPJ zRDcArygbyb25WwAwhXUfMmDiXzluBBAceI2WPYzzZZIG61xoNK898Z314XKUGUjZfQ== X-Gm-Gg: Acq92OEj92i9IzjXlzjr6BX875XCgX9zc368ZiJ/t7730qL47KK2dg/pFfsjcAfP53R utHEczJGwiiwNPXowXdsRI5K0EHDIuvutgWelqw/ygZ/hvnUwMU0VxMwXqxVuwimuRSVFTbDUYq 9hX773pbItShXw5K41+7dFNDiLtI62IjJLWofF8AewY1xkWROoEQ5sZkhd/oF/DY/g7eEUZxvaR ze9ykEL12Tcp4yv9N3XCa9EGYvuzOyz32E69B5Z0BxTZzUdPha9bNBWz+yl6lt1F2xJYQ3xMKfs 8RLCcmWJDid1IXlvQhDPxpJqlfcw05+TPIi9R/yn128BVdJTBIMPd5T5t0heDUtBMeJU1eTOOWf fpXqa4I+kAX4OABpQTmd6NwphfHkiZ93zZjDQrKjkGL5BLQvEdDesdWtBgqBp X-Received: by 2002:a5d:64c7:0:b0:43d:68ad:3b7f with SMTP id ffacd0b85a97d-45c59228b05mr4395324f8f.21.1778669670751; Wed, 13 May 2026 03:54:30 -0700 (PDT) X-Received: by 2002:a5d:64c7:0:b0:43d:68ad:3b7f with SMTP id ffacd0b85a97d-45c59228b05mr4395279f8f.21.1778669670260; Wed, 13 May 2026 03:54:30 -0700 (PDT) Received: from stex1 (host-87-16-204-231.retail.telecomitalia.it. [87.16.204.231]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-454917d57aesm40237869f8f.26.2026.05.13.03.54.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 03:54:29 -0700 (PDT) From: Stefano Garzarella To: netdev@vger.kernel.org Cc: Xuan Zhuo , "Michael S. Tsirkin" , =?UTF-8?q?Eugenio=20P=C3=A9rez?= , linux-kernel@vger.kernel.org, Simon Horman , Paolo Abeni , Jakub Kicinski , Stefano Garzarella , Jason Wang , kvm@vger.kernel.org, Stefan Hajnoczi , virtualization@lists.linux.dev, Eric Dumazet , "David S. Miller" Subject: [PATCH net v3 2/2] vsock/virtio: fix skb overhead accounting to preserve full buf_alloc Date: Wed, 13 May 2026 12:54:17 +0200 Message-ID: <20260513105417.56761-3-sgarzare@redhat.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260513105417.56761-1-sgarzare@redhat.com> References: <20260513105417.56761-1-sgarzare@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stefano Garzarella After commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"), virtio_transport_inc_rx_pkt() subtracts per-skb overhead from buf_alloc when checking whether a new packet fits. This reduces the effective receive buffer below what the user configured via SO_VM_SOCKETS_BUFFER_SIZE, causing legitimate data packets to be silently dropped and applications that rely on the full buffer size to deadlock. Also, the reduced space is not communicated to the remote peer, so its credit calculation accounts more credit than the receiver will actually accept, causing data loss (there is no retransmission). With this approach we currently have failures in tools/testing/vsock/vsock_test.c. Test 18 sometimes fails, while test 22 always fails in this way: 18 - SOCK_STREAM MSG_ZEROCOPY...hash mismatch 22 - SOCK_STREAM virtio credit update + SO_RCVLOWAT...send failed: Resource temporarily unavailable Fix this by using `buf_alloc * 2` as the total budget for payload plus skb overhead in virtio_transport_inc_rx_pkt(), similar to how SO_RCVBUF is doubled to reserve space for sk_buff metadata. This preserves the full buf_alloc for payload under normal operation, while still bounding the skb queue growth. With this patch, all tests in tools/testing/vsock/vsock_test.c are now passing again. Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Signed-off-by: Stefano Garzarella --- net/vmw_vsock/virtio_transport_common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 4a4ac69d1ad1..e22117bf5dcd 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -434,7 +434,10 @@ static bool virtio_transport_inc_rx_pkt(struct virtio_= vsock_sock *vvs, { u64 skb_overhead =3D (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0= ); =20 - if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc) + /* Use buf_alloc * 2 as total budget (payload + overhead), similar to + * how SO_RCVBUF is doubled to reserve space for sk_buff metadata. + */ + if (skb_overhead + vvs->buf_used + len > (u64)vvs->buf_alloc * 2) return false; =20 vvs->rx_bytes +=3D len; --=20 2.54.0