Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4312 bytes --]

On Thu, Jun 25, 2026 at 12:56:59AM +0200, Stefano Brivio wrote:
> On Mon, 22 Jun 2026 11:46:45 +1000
> David Gibson <david@gibson.dropbear.id.au> 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 <jmaloy@redhat.com> 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 <jmaloy@redhat.com>
> > > > 
> > > > ---
> > > > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]