From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id DBD145A031A for ; Thu, 11 Jul 2024 03:54:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1720662836; bh=4iSwWBCJay/V0WkQQ6tKxenm4qYTnttbHq8qL376wrM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OwHxNbKiclFjhTnxosXHTPtKU8+OcZE+2Ilp1wH/8S6GglUCmsMfz9PlKUFNrQiTq /j4EZMSuwVUyXE9tNz+DTV/AsT7MsUz3aCooizr6CZEiubNr8GPeZJKUJBVr/Bw6no aAwjzMR7QDv4vu7jSbtRKVl7lsBmlGbHG8oXrmBGZLoivfznK+gZf7qjiHlbSCQM0s IVMjZ/AhpYhD92OTU9p19Jg9b29FLR6LYTPkTkxdJHXtTQzR4bbhA4dga1pbkshMMj eyhucBIXd69HVkdxj9WQITeIU5JVhmI+pDNbgPh2ieNMldFLVKiLTHTMiuS8Aokh52 wg49EOPzJFSww== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WKHnw4f3yz4x0C; Thu, 11 Jul 2024 11:53:56 +1000 (AEST) Date: Thu, 11 Jul 2024 11:30:52 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v7 21/27] udp: Handle "spliced" datagrams with per-flow sockets Message-ID: References: <20240705020724.3447719-1-david@gibson.dropbear.id.au> <20240705020724.3447719-22-david@gibson.dropbear.id.au> <20240710003233.1d9937fd@elisabeth> <20240710191316.53b7ac5d@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y4swWf9+2IIAScW6" Content-Disposition: inline In-Reply-To: <20240710191316.53b7ac5d@elisabeth> Message-ID-Hash: C2AIDEGQNY5GZQNXONEZ5AEANA7KDJC2 X-Message-ID-Hash: C2AIDEGQNY5GZQNXONEZ5AEANA7KDJC2 X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, jmaloy@redhat.com X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Y4swWf9+2IIAScW6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2024 at 07:13:26PM +0200, Stefano Brivio wrote: > On Wed, 10 Jul 2024 10:23:14 +1000 > David Gibson wrote: >=20 > > On Wed, Jul 10, 2024 at 12:32:33AM +0200, Stefano Brivio wrote: > > > On Fri, 5 Jul 2024 12:07:18 +1000 > > > David Gibson wrote: [snip] > > > > + uflow->s[INISIDE] =3D fcntl(s_ini, F_DUPFD_CLOEXEC, 0); =20 > > >=20 > > > There's one aspect of this I don't understand: if s_ini is closed whi= le > > > checking for bound ports (is it? I didn't really reach the end of this > > > series), aren't duplicates also closed? > > >=20 > > > That is, the documentation of dup2(2), which should be the same for > > > this purpose, states that the duplicate inherits "file status flags", > > > which I would assume also includes the fact that a socket is closed. I > > > didn't test that though. =20 > >=20 > > I don't believe so. My understanding is that dup() (and the rest) > > make a new fd referencing the same underlying file object, yes. But > > AIUI, close() just closes one fd - the underlying object is only > > closed only when all fds are gone. >=20 > Ah, probably, yes. >=20 > > > If duplicates are closed, I guess an alternative solution could be to > > > introduce some kind of reference counting for sockets... somewhere. = =20 > >=20 > > .. in other words, I believe the kernel does the reference counting. > >=20 > > I should verify this though, I'll try to come up with something new > > for doc/platform-requirements. >=20 > I didn't really find the time to sketch this but I guess the easiest > way to check this behaviour is to have a TCP connection between a > socket pair, with one socket having two descriptors, then closing one > descriptor and check if the peer socket sees a closed connection > (recv() returning 0 or similar). So.. yes, this would check whether close() on a non-last fd for a socket triggers socket closing actions, but that's much stricter than what we actually need here. I would, for example, expect shutdown() on a TCP socket to affect all dups - and I don't actually know if a close() on one dup might trigger that. But we're dealing with UDP here, so there's no "on wire" effect of a close. So all we actually need to check is: 1. Open a "listening" udp socket 2. Dup it 3. Close a dup 4. Can the remaining dup still receive datagrams? I've written a test program for this, which I'll include in the next spin. > I was wondering whether it's worth to use the vforked namespaced peer > trick I drafted here: > https://archives.passt.top/passt-dev/20231206160808.3d312733@elisabeth/ >=20 > just in case we want to use some of those test cases for actual tests, > where we don't want to bind an actual TCP port on the machine we're > running on. But if it adds complexity I'd say it's not worth it. Yeah, I tend to think we can add that sort of sandboxing when and if we need it. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --Y4swWf9+2IIAScW6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmaPNcsACgkQzQJF27ox 2GdF2A/9Fswb9csvvt7wVSkoILWYJrlIpVa3qRcQa9gr39uBOcxIZg/CeROCMvez jKsEeHawVJMpOSPACVM6pDm7e7sEzpGWsqwipUefbSNcIqpoLzttbQfbkmnA85ie UC0DOZr2aTaI1ZLHrWopmRcAAphkSzo7cqYFA6b/CDCPwo0v5NAElQfl9VjwWbkW t9pYo9iM4q4YkqcDwqTlwj2Mcx1x6polGm4Sz5pavgtJta66dK8sHRej/XNiKnh1 IROS9rxXd9coMUdjvOHUkikrxquT8mjGFM6DkbeQ+rEdcRw/wDxOgCtrmbWEJfVH BztImHZnbTMd0CDolOur3WP/hlSm1P0LO2XlB5fMHe/0Fo6W5+Hr9lR5apBTLQKr UN7FX0/d/JWtfx6A/BNaDiEAL96E0WV+a5dLAlhCqlny56IOntsTzq3jMwUrGKpQ Av9RA37Fy9XAsu09hYsYqMwax+Y5XEB0mUyjpUDdWPKh+kKMaJrMhkoZBwhZrZad XVwEdo4HwN7wdz6WXxrYLplxXRBdK+CKXRix0e/VbdcqB7+4XD2k6LIaQWNR8Y97 Xj7YGSR9MmTysHkLNtMq0gj4E7ASd+wyZxawS2CkYvQ2udb5ZJzBy3s2DdChUL+N BDUu7ODe2SRs5uD9xJySkC1BASK5Da8sQtiBbASvAUlbTMdKdO4= =25qe -----END PGP SIGNATURE----- --Y4swWf9+2IIAScW6--