From nobody Mon Feb 9 18:21:31 2026 Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [185.226.149.38]) (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 940BA23AE9A; Wed, 21 May 2025 23:18:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.38 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747869534; cv=none; b=alrflaZBiNJXyEH+OAG2RGVu4j222fYhfCSwSHQt5ATCClBmgATibsRrs5wCWm1CxNeNLr9j7RJfzHCIG3rlE4wTgL8nnEeb6ZtH7WLHoHGP8RWJz+bHq66caDATcBip7TtG/8+76BnytRamcUGyOornF04T96RUtppNfqxMieg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747869534; c=relaxed/simple; bh=Bisvp9WXtx0uaSzm4IId2G0NuCg21iZTRlMs7KZj3Zs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=hEZUI3EebuanBhgyvSfh6kA4lcuu6OU8ZSkUdoJA9Stu8BJPyoYKt2dLsUwrb45DDszd3I++IAmQ15a3WMwVMNEHdvzGuXDEDIiJ7MP9TTk0fXzEhKuYZGTuer4+cvXB9fEjCatpImb9QRxVVOmNWzHDnbE+2hv0rSoa7F9v/Bk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co; spf=pass smtp.mailfrom=rbox.co; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b=ZwF+pWC9; arc=none smtp.client-ip=185.226.149.38 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rbox.co Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b="ZwF+pWC9" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1uHsi2-004InU-Mc; Thu, 22 May 2025 01:18:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector2; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=bJE5agG6suW5EMhVSS9xIoPl9te7wqkSo/E38GSN3wQ=; b=ZwF+pWC9N+a6izj/Tx8LNlo1jX FJVIKGjZ1AyRXnPTu+DAQ1Cgc7jnpa9oH84lhc8WN8dQ0V2CvnCrvFsAkHl1t8uQl3EONWgLKe1BP 8o6eLKi5dNaZfBnvOWL0oZg5WZURWDfFvZ40PMzt+6eVtSo0uoerLCcUUV0lOSENAB0ZXZAlPdGUZ X1EYqmFdrIioxDynIb9Kq9uTAjflrNGd1tCnfPWwKyJbOWr/vzT2NFa8RUA+4rGGSG/KawGXeooA/ QO/aRu8TyLUrg/ECCXlbQVs1iw4rvSmCDepvdWU3SYLHAF1c5+l7rn4Hr/Bys551qNmq8cmAz9Af+ bO6YopJQ==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1uHsi2-0000kD-D2; Thu, 22 May 2025 01:18:50 +0200 Received: by submission02.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1uHshq-002oFI-VJ; Thu, 22 May 2025 01:18:39 +0200 From: Michal Luczaj Date: Thu, 22 May 2025 01:18:21 +0200 Subject: [PATCH net-next v6 1/5] vsock/virtio: Linger on unsent data Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250522-vsock-linger-v6-1-2ad00b0e447e@rbox.co> References: <20250522-vsock-linger-v6-0-2ad00b0e447e@rbox.co> In-Reply-To: <20250522-vsock-linger-v6-0-2ad00b0e447e@rbox.co> To: Stefano Garzarella , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?utf-8?q?Eugenio_P=C3=A9rez?= , Stefan Hajnoczi Cc: virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Michal Luczaj X-Mailer: b4 0.14.2 Currently vsock's lingering effectively boils down to waiting (or timing out) until packets are consumed or dropped by the peer; be it by receiving the data, closing or shutting down the connection. To align with the semantics described in the SO_LINGER section of man socket(7) and to mimic AF_INET's behaviour more closely, change the logic of a lingering close(): instead of waiting for all data to be handled, block until data is considered sent from the vsock's transport point of view. That is until worker picks the packets for processing and decrements virtio_vsock_sock::bytes_unsent down to 0. Note that (some interpretation of) lingering was always limited to transports that called virtio_transport_wait_close() on transport release. This does not change, i.e. under Hyper-V and VMCI no lingering would be observed. The implementation does not adhere strictly to man page's interpretation of SO_LINGER: shutdown() will not trigger the lingering. This follows AF_INET. Reviewed-by: Stefano Garzarella Signed-off-by: Michal Luczaj --- net/vmw_vsock/virtio_transport_common.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio= _transport_common.c index 6e7b727c781c88674c147b7b75f49f4f1c670d38..f2f1b166731b1bf2baa3db2854d= e19aa331128ea 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1195,12 +1195,14 @@ static void virtio_transport_wait_close(struct sock= *sk, long timeout) { if (timeout) { DEFINE_WAIT_FUNC(wait, woken_wake_function); + struct vsock_sock *vsk =3D vsock_sk(sk); =20 add_wait_queue(sk_sleep(sk), &wait); =20 do { if (sk_wait_event(sk, &timeout, - sock_flag(sk, SOCK_DONE), &wait)) + virtio_transport_unsent_bytes(vsk) =3D=3D 0, + &wait)) break; } while (!signal_pending(current) && timeout); =20 --=20 2.49.0