From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202606 header.b=QD1p4htd; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 53F3C5A0265 for ; Thu, 09 Jul 2026 07:56:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1783576574; bh=hQXA3zyYFuF+v4evIA7sR4iJFnw1X/zzQpQJSxMjjjw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QD1p4htdYZHiPwL+SZrdkFUxsrz7qQxsmoSXPHsliQHf7IlNCbPHar2urO+kxk3cN 7XqILeypEysSlGO95U1OK9ndQNlo8xCYgSn04gohl+pCGRWXGB2RO/EKBMeBkPenqM 7Co3UGXsIU5ohmZItVM2Qrgm40/oQN+AZgo9uWvY3eOnsY5EbOgDUkC/pRb7JzNWX1 fwh6PCakiKdPkmfzRp6xwKb0javWlNcgvFmMEGVk+zMp4bzsyqQSeifixuAoFjJcmB /OLVcs8/suheUKxA269NWgUSKv9TYzTVEJ9blVW5yEHAbko4qM43RQK38oCkIh9V1/ eb2m8rUTZ1zDA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gwkjV4hS8z58dT; Thu, 09 Jul 2026 15:56:14 +1000 (AEST) Date: Thu, 9 Jul 2026 15:56:08 +1000 From: David Gibson To: Jon Maloy Subject: Re: [PATCH v8 02/14] passt, pasta: Introduce unified multi-address data structures Message-ID: References: <20260626024519.3701556-1-jmaloy@redhat.com> <20260626024519.3701556-3-jmaloy@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UxgxcWsZjU9lUc3b" Content-Disposition: inline In-Reply-To: Message-ID-Hash: JSQSMQWDQDM35HXB2YM64XWKHJDMSFOV X-Message-ID-Hash: JSQSMQWDQDM35HXB2YM64XWKHJDMSFOV 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: sbrivio@redhat.com, passt-dev@passt.top 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: --UxgxcWsZjU9lUc3b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2026 at 02:05:11PM +1000, David Gibson wrote: > On Thu, Jun 25, 2026 at 10:45:07PM -0400, Jon Maloy wrote: > > As preparation for supporting multiple addresses per interface, > > we replace the single addr/prefix_len fields with an array. The > > array consists of a new struct inany_addr_entry containing an > > address and prefix length, both in inany_addr format. > >=20 > > Despite some code refactoring, there are only two real functional > > changes: > > - The indicated IPv6 prefix length is now properly stored, instead > > of being ignored and overridden with the hardcoded value 64, as > > has been the case until now. > > - Since even IPv4 addresses now are stored in IPv6 format, we > > also store the corresponding prefix length in that format, > > i.e. using the range [96,128] instead of [0,32]. > >=20 > > In conf_ip6(), the explicit IN6_IS_ADDR_UNSPECIFIED() check on the > > address at the end of the function is no longer needed: for > > host-discovered addresses, it is now checked inside the if (!a) block > > before calling fwd_set_addr(); for user-provided addresses (via -a), > > validation already rejects unspecified addresses at parse time. Following up with a more general observation. We've now been through a bunch of iterations with various problems in the filtering logic of fwd_get_addr(). On reflection I think the whole idea of a single "get" function with a couple of mask parameters is flawed. The conditions we want to filter on are more complex than this, because we do have both different provenances of address and types of address. The major use of fwd_get_addr() in these early patches is to replace direct references to c->ip4.addr, c->ip6.addr or c->ip6.addr_ll. In later patches, many of these go away, because you instead iterate through and do something for *all* relevant addresses. So, I'd suggest instead of trying to make this general-but-actually-it's-not lookup function you instead insert 3 specific functions: one that retreives an ip4.addr equivalent address, one an ip6.addr equivalent and so forth. That removes the evidently confusing filtering logic of fwd_get_addr() and makes for smaller and clearer changes in the many places that need to be changed to use the new data structure. Through the rest of the patches callers of those will mostly go away, and they can be removed again. --=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 --UxgxcWsZjU9lUc3b Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpPN90ACgkQzQJF27ox 2GcWIQ//dG5ykax/PAtOnQ0gABaOG5ft/J9WD8BgMv/1VfI5lJETtQNyCv9rzxQr IAjjS2CtHCpb+Z5Qa1jGH5oLfS8YYYdYSCBe/xzH3souG9BdYlVc37MXUjGVWBfu m9QZ+IV4rLrJxb4K8mNvqi8kygfEaWtqMeQ3JJf1gKe2F+NUsfdmLCBRNiAE1MoV /ft7y1bVJ47B7erHJHJu/7bt+YyiMPgL5tbV/N60JSkoVzhsja+4poTWESTB8Sf2 W5hA7fTF3qseuZEm+3FWdAGFi9fcOZ506viBxvHsQsk7CWZhl43zbvGO+6kLg19X GzJn+u41hxZXhlnJ1Hj6JmaIjSsX/8Nzl4/iJqTJlpOMIrAU4mnVGYg5AOfADmV5 kou0elS8pyJbI121BUox8ofARKBg/bGJ/Njz0fI7pkRywGs2tucE9zxZuDlCvasf XMQcdXIlQQixdLOmLf0C2+YF8HjFLfuXT5BNTzRTqfmFH3q6vmemnf7XkxRz8OWq Wfc0gMykjq468t3+g0mKG0vqkpaJ2a00vAWCewOiGebb6Ab6VQddcWNYsXDd/NYA jyr826KKqdPhQmN/BqyXb4tf8PwXpS9K3PvnY2Wekqbz8XtsCZO4+vrJ5daLh6bM bPNM7CjXfXo0ZR1POWwmq+kiNnH9cWlLb37+YeRMsiECRdbzT5g= =6po1 -----END PGP SIGNATURE----- --UxgxcWsZjU9lUc3b--