On Fri, Apr 11, 2025 at 11:14:38AM +0200, Stefano
Brivio wrote:
Not really valuable by itself, but dropping one
level of nested blocks
makes the next change more convenient.
No functional changes intended.
Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>
Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au>
Not in scope for this code motion, but I did spot another bug here..
---
conf.c | 101 ++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 60 insertions(+), 41 deletions(-)
diff --git a/conf.c b/conf.c
index 168646f..18ed11c 100644
--- a/conf.c
+++ b/conf.c
@@ -414,6 +414,62 @@ static unsigned add_dns6(struct ctx *c, const struct in6_addr
*addr,
return 1;
}
+/**
+ * add_dns_resolv4() - Possibly add one IPv4 nameserver from host's resolv.conf
+ * @c: Execution context
+ * @ns: Nameserver address
+ * @idx: Pointer to index of current IPv4 resolver entry, set on return
+ */
+static void add_dns_resolv4(struct ctx *c, struct in_addr *ns, unsigned *idx)
+{
+ if (IN4_IS_ADDR_UNSPECIFIED(&c->ip4.dns_host))
+ c->ip4.dns_host = *ns;
+
+ /* Special handling if guest or container can only access local
+ * addresses via redirect, or if the host gateway is also a resolver and
+ * we shadow its address
+ */
+ if (IN4_IS_ADDR_LOOPBACK(ns) ||
+ IN4_ARE_ADDR_EQUAL(ns, &c->ip4.map_host_loopback)) {
The second bit here is wrong. We check if the nameserver address is
the --map-host-loopback address - meaning we can't use it in the
guest - then try to use it in the guest anyway. That path should
instead return, like the ns == 127.0.0.1 && map_host_loopback ==
0.0.0.0 case.
I'm not sure why we can't use the --map-host-loopback address in the
guest. DNS traffic has the priority, right?
Together with 2/2, do you still see an issue?
That is, if there's no --dns-forward and no address maps to a local
resolver, there's no way to reach the local resolver and we return, but
in any other case, I guess we can pick that address.
--
Stefano