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=KemR6qNb; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 6EB1C5A026E for ; Mon, 29 Jun 2026 21:47:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782762426; 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=odB2aiFSUKDgN/suwBDVH5NZQJEJ4Lon+mzQb3HrQug=; b=KemR6qNbZIas54vDyvlgQ1winPBWtWI+bbV0iPh2GkdGtMKfZUf2HgV6LABS7VlukU7Ml/ yzjzWGeiP8suowyDOk5Y40jaJ5PFqzkSTw+BukM0wSA2FJVZRyrOZpQ+Fachj+j7z69zXl he0q3xbtZWOL1R4Nn2RVlktB3KIwNyk= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-115-j1J33QwAMeytWsiRu1-EVQ-1; Mon, 29 Jun 2026 15:47:04 -0400 X-MC-Unique: j1J33QwAMeytWsiRu1-EVQ-1 X-Mimecast-MFC-AGG-ID: j1J33QwAMeytWsiRu1-EVQ_1782762424 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-4740be00302so963647f8f.2 for ; Mon, 29 Jun 2026 12:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782762423; x=1783367223; 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=odB2aiFSUKDgN/suwBDVH5NZQJEJ4Lon+mzQb3HrQug=; b=nhZYxAd526uSdndoXBww/Ys7Ck62NZTkiE6hr3UfCVt/+6AElU1tusnvPPiD4XeRy3 oo5NY4D8cbVuBFZU+F2cr93etFiJGKY+GW7Tfuax+75owMK7VFDsRkvuA9DyRJ4GhjFU j+f4fM6dzzkl6rBixh4Iv/gF0q6JUH6u8x0YIz+ciYp7aJeqO/9Smujy0K3fzBwdcGp8 HW7u4fkHHnWaXAGIAEMfGq8vbBFue5tZ9Zlnj3X9cIntqyk6JYq3CNWvAvdWg1KqeoLl 64WTpuIv4VT/of9HRU+iMqpYkOMqKkeSkq8eFklljikZY9lRa9yjHLJQflAoqpVB/9Qs qMSQ== X-Forwarded-Encrypted: i=1; AHgh+Rp1jjlMOic2uEyr+empGLk1NsOJqASNHA5isrWXpWDoNcgMfU3q+Vdhig7fbwRqwB6NWYx3oqLOqso=@passt.top X-Gm-Message-State: AOJu0Yx153SylUitSVHIBP4dsUdS/eIX3SjIhsM3ezdaJEuWRMGQt03c E2syYKKHN5amuUJaUWTxGUGBAkiUwV/BWT9ZeijzI7XCQUylFTN4NFyGm7Jvs/okcCXZ+D7Ac4N x9iQ17FXmOfDqzzbrV9fyZyUCx+6hbaln26Gy4iACyK7ksdxBS1cErg== X-Gm-Gg: AfdE7cmOptXXUWWc1RoMZ4TyXvk50DKMUopkqwtewiIOgMjnZp2d3EhVq3ER7PPKqlS WNgnnwta5JvMNQIY2pZDH8isNxAOAd8wWRgCeCuBIzgaYhwuu4kVsFbCm5clEtRLmznDUdUsUub kFozNIdZx9xA9bA1s24o1gwh9rTNJu71KFmogOIgltEKn6U/s3odFvAOiBv52AXNsHyZ6y42Wtc N2CldwXorZs1eFi7k00ujTxXpcO/aVhbVH3FegZl1Huw4BzpVHz/g8dr+y61xjEFcSLLjE2bo8W zJcH1btQak49JqBdBrN0mZCOXB5gDtYdL+/QSOPf8hsmW3DIrxeYq6aX9fGSN+MO1iRfqC0GxLy QKJ2ZrMwgGXfkM06l7mmn4djtg5egDa4ULi2LVf4= X-Received: by 2002:a05:6000:2304:b0:46e:2e64:a3e8 with SMTP id ffacd0b85a97d-475524a858emr796073f8f.24.1782762423484; Mon, 29 Jun 2026 12:47:03 -0700 (PDT) X-Received: by 2002:a05:6000:2304:b0:46e:2e64:a3e8 with SMTP id ffacd0b85a97d-475524a858emr796041f8f.24.1782762422961; Mon, 29 Jun 2026 12:47:02 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47563e0eee5sm617922f8f.5.2026.06.29.12.47.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 12:47:01 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array Message-ID: <20260629214700.574c52cf@elisabeth> In-Reply-To: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-9-jmaloy@redhat.com> <20260620001040.76c9d2b1@elisabeth> <20260625005659.47d0b293@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 29 Jun 2026 21:47:01 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: y9b_oOOLyuIl8HifbXLhhiIpaR3xe0AAQIP4RSHYuvE_1782762424 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 2BSSGPSBYN5MBHSB5ENMY6LYP4FFXNXQ X-Message-ID-Hash: 2BSSGPSBYN5MBHSB5ENMY6LYP4FFXNXQ 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 Mon, 29 Jun 2026 18:39:32 +1000 David Gibson wrote: > 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/? Oops, yes. > 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. Why should it ever fail? In that case, if the guest tries to use the gateway address, so be it. It will be unable to reach the host using default options, but then it's probably desired. I actually tried it a while ago, it worked. > > 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. Right, yes, but I've never ever seen DAD-like ARP implemented by anything that's _not_ a DHCP client. Linux doesn't do it, ifcfg scripts / systemd-networkd / NetworkManager don't do it either, so it sounds quite unlikely to me. -- Stefano