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: > > > 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: > > > > > > > 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. > > > > > > > > The observed IPv4 address is always added at or moved to position 0, > > > > increasing chances for a fast lookup. > > > > > > > > Signed-off-by: Jon Maloy > > > > > > > > --- > > > > 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 protocol > > > > o I kept the memmove() calls, since I find no more elegant way to > > > > do this. Performance cost should be minimal, since these parts > > > > of the code will execute only very exceptionally. Note that > > > > removing the 'oldest' entry implicitly means removing the least > > > > used one, since the latter will migrate to the highest position > > > > 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-only > > > > address per protocol, as suggested by David. > > > > > > 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. > > > > 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. > > > > 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. > > 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: > > if (IN6_IS_ADDR_UNSPECIFIED(saddr)) > return 1; > > 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. -- 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