From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 DE9F321D3C7; Wed, 21 May 2025 23:17:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747869465; cv=none; b=Vu7EIfbC4Ow93q7p5Nv4b/iDg2/O2ZKRn4axr7JtGa3PJJZlCVZr/s7QmHVeEAIcaUaVy5s3GY8o8z+YcCwZKPGYbvTndou6p24tlQMu09n8cy54jJDaiDOj99DRDMxmV/4ZbPsxhDKVvFnm/fv7uh05cvmltx3gPsdry9e+13Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747869465; c=relaxed/simple; bh=XD4kuLxj1fx4ZHbQefTh9vvwweTOThXfuO8z55u63YM=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=qyoYc0oxziwRj1S2iycgA00xrBGYWSsa/M0gAZjY7ltL1YIQboz3M9gUEgaOiqPdQPISxujxKA7NDeE53zxD3slPB1zAZD407x9rJUO2Y2JQXk0eRZ0G9wqXtV99XmLY+0AfRi8GqHowNHbRj9XRF0Scdwo0lviCaKtVoPQAiVU= 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=WJBv9E4h; arc=none smtp.client-ip=185.226.149.37 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="WJBv9E4h" Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1uHsgn-004RiA-NY; Thu, 22 May 2025 01:17:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Cc:To:Subject:From:MIME-Version:Date:Message-ID; bh=9nCmsaQp2owCm1/M2mf/Yw6FBV7gBVkunZx8ik/qseA=; b=WJBv9E4hKmylS07aHF/YU+FbuP 8ehnptW1MXqqeUfL87/y/krTUGmwoTEgALVRs41FreeuoePdkBy/9XVeiiBUE21Hpsozl9wrMRh2+ tsYsrQPF+05JkesmYLwTo+S/NtupSL/BfIYw89hINZ3hs4Zsgd4tVO28lDMbcKHIcCucZWC0q5IEE MXXaATM8nIfce8kjNrT8evopyeMiMT51s3iJ6/9t1n6S23xMdhk/qM0IJh1iuQQ+7htADC64IiSXu AvKKOWeVCdtaynQhkajR+MZ9P/CI95KH0lwIYOSdRd8SSDTjDMGcnTro0ioEnImCTbYbBY2DNypdO ji8AHLZQ==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1uHsgm-0006E7-Hp; Thu, 22 May 2025 01:17:32 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1uHsgl-000gSv-IM; Thu, 22 May 2025 01:17:31 +0200 Message-ID: <5dc16a14-e66c-4e1d-896f-a8483cdf0f04@rbox.co> Date: Thu, 22 May 2025 01:17:30 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Michal Luczaj Subject: Re: [PATCH net-next v5 5/5] vsock/test: Add test for an unexpectedly lingering close() To: Stefano Garzarella Cc: "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 , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20250521-vsock-linger-v5-0-94827860d1d6@rbox.co> <20250521-vsock-linger-v5-5-94827860d1d6@rbox.co> Content-Language: pl-PL, en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/21/25 16:56, Stefano Garzarella wrote: > On Wed, May 21, 2025 at 12:55:23AM +0200, Michal Luczaj wrote: >> There was an issue with SO_LINGER: instead of blocking until all queued >> messages for the socket have been successfully sent (or the linger timeout >> has been reached), close() would block until packets were handled by the >> peer. >> >> Add a test to alert on close() lingering when it should not. >> >> Signed-off-by: Michal Luczaj >> --- >> tools/testing/vsock/vsock_test.c | 49 ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c >> index f401c6a79495bc7fda97012e5bfeabec7dbfb60a..1040503333cf315e52592c876f2c1809b36fdfdb 100644 >> --- a/tools/testing/vsock/vsock_test.c >> +++ b/tools/testing/vsock/vsock_test.c >> @@ -1839,6 +1839,50 @@ static void test_stream_linger_server(const struct test_opts *opts) >> close(fd); >> } >> >> +static void test_stream_nolinger_client(const struct test_opts *opts) >> +{ >> + bool nowait; >> + time_t ns; >> + int fd; >> + >> + fd = vsock_stream_connect(opts->peer_cid, opts->peer_port); >> + if (fd < 0) { >> + perror("connect"); >> + exit(EXIT_FAILURE); >> + } >> + >> + enable_so_linger(fd); > > If we use a parameter for the linger timeout, IMO will be easy to > understand this test, defining the timeout in this test, set it and > check the value, without defining LINGER_TIMEOUT in util.h. Yes, you're right. I'll fix that. >> + send_byte(fd, 1, 0); /* Left unread to expose incorrect behaviour. */ >> + nowait = vsock_wait_sent(fd); >> + >> + ns = current_nsec(); >> + close(fd); >> + ns = current_nsec() - ns; >> + >> + if (nowait) { >> + fprintf(stderr, "Test skipped, SIOCOUTQ not supported.\n"); >> + } else if ((ns + NSEC_PER_SEC - 1) / NSEC_PER_SEC >= LINGER_TIMEOUT) { > > Should we define a macro for this conversion? > > Or just use DIV_ROUND_UP: Arrgh, I was looking for that. If you don't care much for a new macro, I'll explicitly use DIV_ROUND_UP for now. Thanks! Michal