From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BEc39o1Q; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 747EF5A0262 for ; Sat, 20 Jun 2026 00:11:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781907070; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Z5cDSqAeQQXl8JRReUbD41Jtr2UMtxsuO7qekO0jcy0=; b=BEc39o1Q3ZZV+82xqRISP/0urt+U8pb+QAbEDxFLArXkM2pPlMbnpHv5m1k2CGLQYzVa5z gYg/Qdby+bl9RpseVi2u2/MrYXqPjaQZ4EyyufRNpOPR+/78YSap+v5vdAV3BJXxMm8Gd+ YMZC/KdCwIBfMCmg0fWhAOhg4ahShHY= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-CoHEHK2dPRate9subrmaRA-1; Fri, 19 Jun 2026 18:11:08 -0400 X-MC-Unique: CoHEHK2dPRate9subrmaRA-1 X-Mimecast-MFC-AGG-ID: CoHEHK2dPRate9subrmaRA_1781907068 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-490d3f03883so16936415e9.1 for ; Fri, 19 Jun 2026 15:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781907068; x=1782511868; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z5cDSqAeQQXl8JRReUbD41Jtr2UMtxsuO7qekO0jcy0=; b=DAOri4ZAKTuUp+9ZocMyd+nBrNtv00BuP2C5A9XtwVs190mCQmN+KEYOLXlIjnNwus qgvIhYXd9WcfODtCWOvIMEWOaikd4cEJiD5iIaooYqqNqdCb6W+aItq1qupsH4iqMgFB OkkTNyjpYjvxfEmtUZ137ulEQw2PUATHkFhXM7y5UuJ1nH9aYI1NaS4dpV6CKQNOtw4X T/dKkIqrWWLOymlUZoT7jIZ0FoLTGy4SxqtzVaPjjK+/V3mECJAaZ4QO8J1KW0S+Hflf 7UCNhSTDcF5uLyoAUn6fKDYN/ew26ouUVPwzPG6Wp/17ibjPvJxI5YDiy7PdLNcPbzq6 OQ2w== X-Forwarded-Encrypted: i=1; AFNElJ+okpL69X+oI0k5DO8Bri+tkRVq7h61PIwcfrb0of+OhU3W2Ly2jcviEIVOHzC25EUO/TOlo9/CqUM=@passt.top X-Gm-Message-State: AOJu0YxVj0kFwGeFmW+YkkaIyE/oQ/5B6jcMRwXEHA0xNibexsgiU6bw r5i6BnvnBVhLJXbJCnm9KECo2pQj4ESUelU0qO3YblIOuuBb7/K1qhToTm2L9vhISxBYPxM1noh LtGT42ThvrX3PJHeN8kF9iqyhx53SJblAHF8k8f9qtp/Ow7RumLB+nw== X-Gm-Gg: AfdE7cmPejIPc12vQLtpdwR59ymuwKfiwhhaOf7XP+MeYvFgapgaL6harKjVlyMjdGf PupW7L+Z+lMKCWTfzPlaDwU8UKeKMTrbsguw1AzF7PzkZmFLLcJBPIg4n0tKMgTkQm5G7eVnpL4 KHQNjRbM9Mfq1t+7zBzefdGCDbzWTgq7o82STZo2EsyrTP2MTjrwLu3W/JLW1laPGwXa1Rx1j9G 5yELUd3v1bJmuWLPN9LAEkzO3mKL/Q6YFV3b7sBPWaWVScJSV8z6p9eRmYea7bodLmkuq7Vdi56 jXFtTvSodEYL3W2ZDTMUT/smY+BD44QptEgQvtqBWe+AlogrAcEmzMtZ2y9xaeq6DJyOmuhaJhG EEuMSzYgibVTMGTNNmlLRMQ== X-Received: by 2002:a7b:cb56:0:b0:490:b65f:8b1 with SMTP id 5b1f17b1804b1-49240e22ed1mr59494485e9.5.1781907067560; Fri, 19 Jun 2026 15:11:07 -0700 (PDT) X-Received: by 2002:a7b:cb56:0:b0:490:b65f:8b1 with SMTP id 5b1f17b1804b1-49240e22ed1mr59494155e9.5.1781907066965; Fri, 19 Jun 2026 15:11:06 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49240f054e3sm86533555e9.2.2026.06.19.15.11.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 15:11:06 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 09/13] conf, pasta: Track observed guest IPv6 addresses in unified address array Message-ID: <20260620001105.1305640c@elisabeth> In-Reply-To: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-10-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Sat, 20 Jun 2026 00:11:06 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: RQkcC9oJ4NX0rfN2qVYIR9GLlf2iVDDeUBwl_r_qBl4_1781907068 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: O2PF7GAUVHULXBKS4NZ6BIB5AILICKAZ X-Message-ID-Hash: O2PF7GAUVHULXBKS4NZ6BIB5AILICKAZ X-MailFrom: sbrivio@redhat.com 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: On Wed, 27 May 2026 13:40:51 +1000 David Gibson wrote: > On Sun, Apr 12, 2026 at 08:53:15PM -0400, Jon Maloy wrote: > > We remove the addr_seen and addr_ll_seen fields in struct ip6_ctx > > and replace them by setting CONF_ADDR_OBSERVED and CONF_ADDR_LINKLOCAL > > flags in the corresponding entry in the unified address array. > > > > The observed IPv6 address is always added/moved to position 0 > > in the array, improving chances for fast lookup. > > > > The separate check against addr_seen in fwd_guest_accessible() can now > > be removed because the observed address is now in the unified array, > > and the existing for_each_addr() loop already checks against all > > addresses, including this one. > > > > This completes the unification of address storage for both IPv4 and > > IPv6, enabling future support for multiple guest addresses per family. > > > > Signed-off-by: Jon Maloy > > > > --- > > v5: - Made to use same algorithm and function as IPv4 for inserting > > observed into the array. > > > > v6: - Re-introduced code that by accident had been moved to the > > previous commit. > > - Some fixes based on feedback from David G. > > > > v7: - Added a commit at the beginning of the series addressing > > Stefano's concern about DHCPv6 reply addresses. > > - Some other updates based on feedback from David and Stefano. > > --- > > conf.c | 4 ---- > > dhcpv6.c | 4 +--- > > fwd.c | 38 +++++++++++++++++++++++--------------- > > inany.h | 3 +++ > > migrate.c | 37 +++++++++++++++++++++++++++---------- > > passt.h | 4 ---- > > pasta.c | 11 +++++++---- > > tap.c | 17 +++++------------ > > 8 files changed, 66 insertions(+), 52 deletions(-) > > > > diff --git a/conf.c b/conf.c > > index f503d0f..3cb3553 100644 > > --- a/conf.c > > +++ b/conf.c > > @@ -827,7 +827,6 @@ static unsigned int conf_ip6(struct ctx *c, unsigned int ifi) > > strerror_(-rc)); > > return 0; > > } > > - a = fwd_get_addr(c, AF_INET6, CONF_ADDR_HOST, 0); > > } else { > > rc = nl_addr_get_ll(nl_sock, ifi, &ip6->our_tap_ll); > > if (rc < 0) { > > @@ -836,9 +835,6 @@ static unsigned int conf_ip6(struct ctx *c, unsigned int ifi) > > } > > } > > > > - if (a) > > - ip6->addr_seen = a->addr.a6; > > - > > if (IN6_IS_ADDR_LINKLOCAL(&ip6->guest_gw)) > > ip6->our_tap_ll = ip6->guest_gw; > > > > diff --git a/dhcpv6.c b/dhcpv6.c > > index 0a064a9..447aaba 100644 > > --- a/dhcpv6.c > > +++ b/dhcpv6.c > > @@ -567,8 +567,8 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > > struct opt_hdr client_id_storage; > > /* cppcheck-suppress [variableScope,unmatchedSuppression] */ > > struct opt_ia_na ia_storage; > > - const struct guest_addr *a; > > const struct in6_addr *src; > > + const struct guest_addr *a; > > struct msg_hdr mh_storage; > > const struct msg_hdr *mh; > > struct udphdr uh_storage; > > @@ -683,8 +683,6 @@ int dhcpv6(struct ctx *c, struct iov_tail *data, > > resp.hdr.xid = mh->xid; > > > > tap_udp6_send(c, src, 547, saddr, 546, mh->xid, &resp, n); > > - if (a) > > - c->ip6.addr_seen = a->addr.a6; > > > > return 1; > > } > > diff --git a/fwd.c b/fwd.c > > index 8c7bf91..b177be9 100644 > > --- a/fwd.c > > +++ b/fwd.c > > @@ -1095,14 +1095,6 @@ static bool fwd_guest_accessible(const struct ctx *c, > > return false; > > } > > > > - /* For IPv6, addr_seen starts unspecified, because we don't know what LL > > - * address the guest will take until we see it. Only check against it > > - * if it has been set to a real address. > > - */ > > - if (!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr_seen) && > > - inany_equals6(addr, &c->ip6.addr_seen)) > > - return false; > > - > > return true; > > } > > > > @@ -1305,10 +1297,20 @@ uint8_t fwd_nat_from_host(const struct ctx *c, > > } > > tgt->oaddr = inany_any4; > > } else { > > - if (c->host_lo_to_ns_lo) > > + if (c->host_lo_to_ns_lo) { > > tgt->eaddr = inany_loopback6; > > - else > > - tgt->eaddr.a6 = c->ip6.addr_seen; > > + } else { > > + const struct guest_addr *a; > > + > > + a = fwd_select_addr(c, AF_INET6, > > + CONF_ADDR_OBSERVED, > > + CONF_ADDR_USER | > > + CONF_ADDR_HOST, > > + CONF_ADDR_LINKLOCAL); > > As for IPv4, do we actually need the two-phase search, or is the > ordering of addresses in the array enough? > > > + if (!a) > > + return PIF_NONE; > > + tgt->eaddr = a->addr; > > + } > > tgt->oaddr = inany_any6; > > } > > > > @@ -1346,10 +1348,16 @@ uint8_t fwd_nat_from_host(const struct ctx *c, > > > > tgt->eaddr = a->addr; > > } else { > > - if (inany_is_linklocal6(&tgt->oaddr)) > > - tgt->eaddr.a6 = c->ip6.addr_ll_seen; > > - else > > - tgt->eaddr.a6 = c->ip6.addr_seen; > > + bool ll = inany_is_linklocal6(&tgt->oaddr); > > + uint8_t excl = ll ? ~CONF_ADDR_LINKLOCAL : CONF_ADDR_LINKLOCAL; > > Uuhhh... I recall Stefano suggested using this encoding technique of > using ~flag to indicate a different meaning. Hmm, no, wait, I was suggesting something different: instead of two incl, excl arguments, a single 'flags' argument which is interpreted as an exclusion mask if an inversion of a single bit is set, so that you could do: fwd_select_addr(c, AF_INET6, CONF_ADDR_OBSERVED); to get observed addresses, and: fwd_select_addr(c, AF_INET6, ~CONF_ADDR_OBSERVED); to get everything else (see that in use in conn_flag_do(), tcp.c). But if multiple bits can be filtered on, that won't work. > But AFACT handling that > encoding is not actually implemented in fwd_get_addr() in this series. The usage here is different: this seems to be meant to exclude link-local addresses (and, I concur, CONF_ADDR_LINKLOCAL should be another type of flag) if tgt->oaddr is not link-local, and exclude all other types if it is. I don't think it will work for all the other types because, if 'll' is false, we'll exclude CONF_ADDR_USER and CONF_ADDR_HOST anyway (which are the only ones being selected), but it's rather an issue with how 'excl' is set rather than a particular encoding. > Plus, that encoding technique doesn't really work any more if you > allow multiple bits in the excl fields. Right, the one I suggested won't work. The one that was intended here should still work, in principle, I guess. > > + const struct guest_addr *a; > > + > > + a = fwd_select_addr(c, AF_INET6, CONF_ADDR_OBSERVED, > > + CONF_ADDR_USER | CONF_ADDR_HOST, excl); > > + if (!a) > > + return PIF_NONE; > > + > > + tgt->eaddr = a->addr; > > } > > > > return PIF_TAP; -- Stefano