From mboxrd@z Thu Jan 1 00:00:00 1970 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 3EC5733065C for ; Wed, 24 Dec 2025 09:16:22 +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=1766567785; cv=none; b=bPh/v4OIcuAK5adadOUGEvMbQ7Ukaqo8z31uTl+2qvXjG+1tQ7bDNu6PmyEfeV0H9UCK8rG4LO2EO35YbRYp0p7e4vvJWOQrmggMRoN58xfsLpbe16A04pCEGUeT3ucvAlyg9QM7HHva5vu1Y7GZVBmNAULp593iKvr89cO6Nko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766567785; c=relaxed/simple; bh=W5FPgoGpUmgPhjWL8T1Mrolt+NR9LunlkkjtHM6j/dA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qOaPWyc532CI7zmyvJzkAwczZnQBbupO6OyAOjWnwYoLn8ZvOeoloV17zUZIMI1uJemmldgaX6aIZ5Qb8HiLuyJl1U9Mrt9P9WnCImVrmRk+v8YAy9V5w9Hs3hN1MMYxCC7cnA6GpVOCkI+ExeUdF5v0bCz48Ckj7McxdMqwKsY= 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=bz9fe//q; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=OY0bHzso; 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="bz9fe//q"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="OY0bHzso" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766567781; 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=TG9qFMYYZ4oH8GV5uabpqY3JSsJR+DkIvS2mHVZ4zRo=; b=bz9fe//qYTWbpmllI4vQrIzc2P+mKeHgcnDdJdGLvbp3gkJbCKCdmfqeZT9lsNV+dPTUDN uwCWHU0VndWzfokrzOJrRgjuL6odF9O8ZNHMzwB74e49Rzn/m2ZB1skimd/JzkaZAHXrgX Mt9yibscDzSKzxSVXdUOsPLZ2gBblT0= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-365-IYPfrsMOO4-EO2xozoNXZA-1; Wed, 24 Dec 2025 04:16:19 -0500 X-MC-Unique: IYPfrsMOO4-EO2xozoNXZA-1 X-Mimecast-MFC-AGG-ID: IYPfrsMOO4-EO2xozoNXZA_1766567779 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-b79f6f91bcbso368528466b.0 for ; Wed, 24 Dec 2025 01:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1766567778; x=1767172578; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=TG9qFMYYZ4oH8GV5uabpqY3JSsJR+DkIvS2mHVZ4zRo=; b=OY0bHzsoISnZV4y0jlNSHyBT3pdxUKDH18bjBQU0f9720/S8PMz5vFTWVWJK/gho/v Jqo8pr+G6Eryb9U/8LGV9rAnqcRTQEchpfOOyt0uDrg0SmB1x+vMUxE9ATJJQJvCFECZ zb1M3WxNVJJbHsM895UhbvlxQWfU1J9Hd4L7zFtdxoDF/+tcE3O1BX+wsP3bq+1nVNMI 5AoOyZXUC6MvtH6KCCXi+KJG4MnysavsyvGV6rQkgvP+52CeIjXpKh+pra+TwLotyA2I OmkmUHZVZ8OMZJJJjrme8ZH+DwmbpdAFvv9SFIvjHs1ig5R+IJztMsfuQAQhwCEnT3cV ij+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766567778; x=1767172578; h=in-reply-to:content-disposition: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; bh=TG9qFMYYZ4oH8GV5uabpqY3JSsJR+DkIvS2mHVZ4zRo=; b=vQymb9BdbXVkLPhKmsHvNs1ivfOIY4nCBs7oZa2dUjBCQJJFEPjuWvozoBhxmb9Fcv atxMuN9la6X04Lx9K4msPSqyePorLowqle9B0FOvFkBhORnONR1XYEkk0rhJmIi9rIy/ Qk1vvOXdLzni3H2NBa2WPl+b7iOyeuD6Zx/7lIHNwuaJN7LGtPAzaPQzkYxedOYiK/4h eaUwm88h4VxEGRl4uYb4Wink8X2QpD8mazRl5rsyxBf4tKN1htzJVBuaNjrEyXiU3Hw+ 2P5G3OA+4iTI0LWp/rEG/WpyatDffUxtr/Yj2/o4PGFLnq8MXEB3Q/5Gsz8yuCisgC6w g3JA== X-Forwarded-Encrypted: i=1; AJvYcCXXUr0cx7f0/FXYeMEjsSJ7e3UtyjV9qVF9UdIYGylOvBfeYKr9AEYUM4XDoSSTuMHJ3ZutfxeZTLE9NU0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2pMSXcXtorsttw3unQDeNDAb9PbYAO9JuBWQ33gHi1XkB6L89 EXYVXJBG31VP4L2pmEYFY5ZeJ0ln/lLXGF1F0rY6ZChZV6X+TkVO/oGEHaueBXKqys4DaA2nXGn l5fzDLQt8FLC85ss8uyI2JHeFestAkDjPJJKzb5WPKr8n3nePy/xDQD7KtvjwNBbSoA== X-Gm-Gg: AY/fxX7T1PreUIfXnZ3IVkzi3NDsuRVlBgZ+41CsWBa+J8MMCHX5+qHAiP5TyOY8Nz2 PBfkBvT3bUGU7cXCM11FgRpPirh4uJvTpHspLD9fFnX+E6EOQGMmfh42ZCa+6n4Ciihb5j0rB4M Pci/NYG4hgajb2lR0bICVI8ZHxR6u13hQaKPFf3+S0bgfs73o3wwv+X4xl2gT5fv4jWn1Bl4q67 3AtstxpazbmxarWjiyBpSna4+kR+gejQjP7peBSvu/VqAtArihQAFt0Y7hm5U8Fv0wE1AKGJex1 O3bsoG0Z9BAlE69ulCV3TGZktwHtomB+HW2sKGvyO04A5FKak95+8kEKPj1vQKq+tZY8vE2k3ip 4LmoeUmLGHodANo5/ X-Received: by 2002:a17:907:7f1c:b0:b83:976:50f9 with SMTP id a640c23a62f3a-b83097652a7mr168592866b.61.1766567778470; Wed, 24 Dec 2025 01:16:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2zROeUVFL1dzpYZqyjYvkN4o8L5fjhHfHOKDDCOidKMgMKBQP5VHD8MGw0Ju06pc+b5i0KA== X-Received: by 2002:a17:907:7f1c:b0:b83:976:50f9 with SMTP id a640c23a62f3a-b83097652a7mr168590266b.61.1766567777909; Wed, 24 Dec 2025 01:16:17 -0800 (PST) Received: from sgarzare-redhat ([193.207.144.111]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8037f0cc52sm1685076666b.52.2025.12.24.01.16.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Dec 2025 01:16:17 -0800 (PST) Date: Wed, 24 Dec 2025 10:15:52 +0100 From: Stefano Garzarella To: Michal Luczaj Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Arseniy Krasnov , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net 2/2] vsock/test: Test setting SO_ZEROCOPY on accept()ed socket Message-ID: References: <20251223-vsock-child-sock-custom-sockopt-v1-0-4654a75d0f58@rbox.co> <20251223-vsock-child-sock-custom-sockopt-v1-2-4654a75d0f58@rbox.co> <1c877a67-778e-424c-8c23-9e4d799fac2f@rbox.co> <8b76f6f8-3f5c-4bea-8084-577712ec028b@rbox.co> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8b76f6f8-3f5c-4bea-8084-577712ec028b@rbox.co> On Tue, Dec 23, 2025 at 09:38:07PM +0100, Michal Luczaj wrote: >On 12/23/25 17:50, Stefano Garzarella wrote: >> On Tue, Dec 23, 2025 at 02:20:33PM +0100, Stefano Garzarella wrote: >>> On Tue, Dec 23, 2025 at 12:10:25PM +0100, Michal Luczaj wrote: >>>> On 12/23/25 11:27, Stefano Garzarella wrote: >>>>> On Tue, Dec 23, 2025 at 10:15:29AM +0100, Michal Luczaj wrote: >>>>>> Make sure setsockopt(SOL_SOCKET, SO_ZEROCOPY) on an accept()ed socket is >>>>>> handled by vsock's implementation. >>>>>> >>>>>> Signed-off-by: Michal Luczaj >>>>>> --- >>>>>> tools/testing/vsock/vsock_test.c | 33 +++++++++++++++++++++++++++++++++ >>>>>> 1 file changed, 33 insertions(+) >>>>>> >>>>>> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c >>>>>> index 9e1250790f33..8ec8f0844e22 100644 >>>>>> --- a/tools/testing/vsock/vsock_test.c >>>>>> +++ b/tools/testing/vsock/vsock_test.c >>>>>> @@ -2192,6 +2192,34 @@ static void test_stream_nolinger_server(const struct test_opts *opts) >>>>>> close(fd); >>>>>> } >>>>>> >>>>>> +static void test_stream_accepted_setsockopt_client(const struct test_opts *opts) >>>>>> +{ >>>>>> + int fd; >>>>>> + >>>>>> + fd = vsock_stream_connect(opts->peer_cid, opts->peer_port); >>>>>> + if (fd < 0) { >>>>>> + perror("connect"); >>>>>> + exit(EXIT_FAILURE); >>>>>> + } >>>>>> + >>>>>> + vsock_wait_remote_close(fd); >> >> On a second look, why we need to wait the remote close? >> can we just have a control message? > >I think we can. I've used vsock_wait_remote_close() simply as a sync >primitive. It's one line of code less. > >> I'm not sure even on that, I mean why this peer can't close the >> connection while the other is checking if it's able to set zerocopy? > >I was worried that without any sync, client-side close() may race >server-side accept(), but I've just checked and it doesn't seem to cause >any issues, at least for the virtio transports. Okay, I see. Feel free to leave it, but if it's not really needed, I'd prefer to keep the tests as simple as possible. > >>>>>> + close(fd); >>>>>> +} >>>>>> + >>>>>> +static void test_stream_accepted_setsockopt_server(const struct test_opts *opts) >>>>>> +{ >>>>>> + int fd; >>>>>> + >>>>>> + fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL); >>>>>> + if (fd < 0) { >>>>>> + perror("accept"); >>>>>> + exit(EXIT_FAILURE); >>>>>> + } >>>>>> + >>>>>> + enable_so_zerocopy_check(fd); >>>>> >>>>> This test is passing on my env also without the patch applied. >>>>> >>>>> Is that expected? >>>> >>>> Oh, no, definitely not. It fails for me: >>>> 36 - SOCK_STREAM accept()ed socket custom setsockopt()...36 - SOCK_STREAM >>>> accept()ed socket custom setsockopt()...setsockopt err: Operation not >>>> supported (95) >>>> setsockopt SO_ZEROCOPY val 1 >>> >>> aaa, right, the server is failing, sorry ;-) >>> >>> Reviewed-by: Stefano Garzarella >>>> >>>> I have no idea what's going on :) >>>> >>> >>> In my suite, I'm checking the client, and if the last test fails only >>> on the server, I'm missing it. I'd fix my suite, and maybe also >>> vsock_test adding another sync point. >> >> Added a full barrier here: >> https://lore.kernel.org/netdev/20251223162210.43976-1-sgarzare@redhat.com > >Which reminds me of discussion in >https://lore.kernel.org/netdev/151bf5fe-c9ca-4244-aa21-8d7b8ff2470f@rbox.co/ Oh, I forgot that we already discussed that. My first attempt was exactly that, but then discovered that it didn't add too much except for the last one since for the others we have 2 full barriers back to back, so I preferred to move outside the loop. In that way we can also be sure the 2 `vsock_tests` are in sync with the amount of tests to run. But yeah, also that one fix the issue. >. Sorry for postponing, I've put it on my vsock-cleanups branch and kept >adding more little fixes, and it was never the right time to post the series. > Nah, don't apologize, you're doing an amazing job! Thanks, Stefano