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=IFjl0R/L; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 132C75A0265 for ; Mon, 29 Jun 2026 11:01:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1782723680; bh=gOvvOJ0fGWeY4ll5mj0yUvI4ALtMCH+P6KvJrJUXYAI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IFjl0R/LqrpOl7h+QenUPa81zhh+kf9BvpkCno1aiBz82SI/khnLM/ofXifmXABHA ARECUbx3GcpJwbyD8+IdLGDIixO6Q6RDlbk2b36J3EvDg5RpZwyT6fPKMg21EkQ/PI N1oOO2U3NqUR/Fg/zULGgAuCBFKkDhTBEuXNsDf3KH0es32ZGraGw4bw65K8rg98nj iaZkfRQ0tRa9+iTGd6No1tSoXc9d5QQmxOlKbHfzflDz3X+u/CaE8v6s1LF0xf/S7W rTWqnCON2+aUZxYcjORhQppxJv2zyF10yy2E//nzVv9iXt+Y0ysWJpEu6TDzjerm8y uxRVqgRaVr9ZA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gpgHh5Wy3z4w23; Mon, 29 Jun 2026 19:01:20 +1000 (AEST) Date: Mon, 29 Jun 2026 18:39:32 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array Message-ID: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-9-jmaloy@redhat.com> <20260620001040.76c9d2b1@elisabeth> <20260625005659.47d0b293@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hq/beUo7sSl+GK1A" Content-Disposition: inline In-Reply-To: <20260625005659.47d0b293@elisabeth> Message-ID-Hash: YHSITJBUSXQKB3PGNI7RUWUVWVEMAXOY X-Message-ID-Hash: YHSITJBUSXQKB3PGNI7RUWUVWVEMAXOY 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: Jon Maloy , 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: --hq/beUo7sSl+GK1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 25, 2026 at 12:56:59AM +0200, Stefano Brivio wrote: > On Mon, 22 Jun 2026 11:46:45 +1000 > David Gibson wrote: >=20 > > On Sat, Jun 20, 2026 at 12:10:41AM +0200, Stefano Brivio wrote: > > > On Sun, 12 Apr 2026 20:53:14 -0400 > > > Jon Maloy wrote: > > > =20 > > > > We remove the addr_seen field in struct ip4_ctx and replace it by > > > > setting a new CONF_ADDR_OBSERVED flag in the corresponding entry > > > > in the unified address array. > > > >=20 > > > > The observed IPv4 address is always added at or moved to position 0, > > > > increasing chances for a fast lookup. > > > >=20 > > > > Signed-off-by: Jon Maloy > > > >=20 > > > > --- > > > > v4: - Removed migration protocol update, to be added in later commit > > > > - Allow only one OBSERVED address at a time > > > > - Some other changes based on feedback from David G > > > > v5: - Allowing multiple observed IPv4 addresses > > > > v6: - Refactored fwd_set_addr(), notably: > > > > o Limited number of allowed observed addresses to four per pr= otocol > > > > o I kept the memmove() calls, since I find no more elegant wa= y to > > > > do this. Performance cost should be minimal, since these pa= rts > > > > of the code will execute only very exceptionally. Note that > > > > removing the 'oldest' entry implicitly means removing the l= east > > > > used one, since the latter will migrate to the highest posi= tion > > > > after a few iterations of remove/add. > > > > o Also kept the prefix_len update. Not sure about this, but I > > > > cannot see how the current approach can cause any harm. > > > > - Other changes suggested by David G, notably reversing some > > > > residues after an accidental merge/re-split with the next > > > > commit. > > > > v7: - Changed fwd_set_addr() to only accept keeping one observed-on= ly > > > > address per protocol, as suggested by David. =20 > > >=20 > > > Sorry, I just spotted this in David's review of v6. Actually, I > > > think that keeping track of a few multiple observed addresses > > > (especially with different scope) might be convenient and it would > > > already be useful here together with 4/13 to avoid resolving via ARP > > > any of a few addresses recently seen from the guest. =20 > >=20 > > So.. not resolving ARPs is the one thing where we could actualy use > > multiple guest observed addresses - mostly we use it for directing > > traffic to the guest, for which we need a single address. > >=20 > > But.. I feel like switching the ARP resolution from "everything > > except" to "only these" would be a better solution. That also lets > > the guest move to a brand new unused address without getting bogus DAD > > failures. >=20 > See my follow-up on 2/13 for the general topic. Specifically about > duplicate address detection: that's NDP, not ARP, Sorry, I spoke sloppily. I was meaning all duplicate address detection techniques, including both true NDP DAD and using ARP for a similar purpose with IPv4. > and it already works > without failures because of this check in ndp(), ndp.c: >=20 > if (IN6_IS_ADDR_UNSPECIFIED(saddr)) > return 1; >=20 > which is based on the fact that duplicate address detection packets are > sent to the unspecified address (RFC 4862, 5.4.2). s/to/from/? So, I hadn't realised that. That basically means DAD will always suceed, even when it should fail - e.g. if the guest tries to use the gateway's address. That doesn't seem great. > The DHCP / ARP equivalent is also taken care of because we assume we > are the relevant DHCP server for any guest / container and in that case > we wouldn't resolve duplicate address probes for IPv4 either, as we > just assigned that address to the guest / container. If the guest uses DHCP, in which case it should be using the address we give it via DHCP. If it _doesn't_ take the address frome DHCP, but does use DAD-like ARP, that will prevent it from changing address. --=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 --hq/beUo7sSl+GK1A Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpCLzoACgkQzQJF27ox 2GfCpRAAkbuDkYIUqXO0ouJimpg4lOzyAX/45DC30ALyHVICgonZeL6UGDr38tTT x0hY45Lii0ifb7NLSb8+gmpMi0Fi1kSnLOpTtEBr30oZcjhazCv2LNjQPZ42vDQh Zj/FqjLgYy70Tkat6CtmLvj89TvEHOFWQKCLJzBL9dC0Lsu4UKii+7WORnQOJ2Av czGAiXgpuxtUMx+pRRSPAnHF6P1k1M5GhNcMGQEaAD/qTM89tV3tbbaOOKBjcVn2 VBZ9ua5FU7RuvAuE73XSH71VBK5qkehjXEaYtfyTaAh71FzXEfg+rBfkK2Q9/+yc +BYs5AdbvLgwgl47fjKEprwkaHVB8k2k8Lw/+eNnlWyha2Z0AdMlOODSt9rMuyln wpFJHBLWhHyGdOXgngwXTrUaaBwGpIr/xz1QVEuFl5qIgOtfMIcOajFUnylqV0jF lRQ5Oigryof3RtoiZcd4ZUrydsghGsIOmQu/gYqzYcLGAg6XG4PKb/R1bGfHhPsw bF2TG5M693inhifCqnKJJvP0xPeJHjLI94ye6mkEW0N/eicer9QGm7nd5rj2lZGq RNFO35fk0oNEIIp3p3ltwupTz+B0UwycM1XEl17K2/IlMB5N2y0IWiqrHBTma9Xb CCwXP8L0YgaVDsM6qlJL+wSxYbenxPuX7pJ79O7MDsC3G+KXSYw= =Hhvd -----END PGP SIGNATURE----- --hq/beUo7sSl+GK1A--