On Mon, 14 Apr 2025 12:05:30 +1000
David Gibson
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
Reviewed-by: David Gibson
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