From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202602 header.b=PZsgbLUL; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id BA4855A0265 for ; Wed, 08 Apr 2026 06:42:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1775623358; bh=A5AW8gazVa8l94gUJto7biLjhaSIBzaFtJzyqzYaMp0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PZsgbLULMyt7ZNry+O76mbw4jonagUrH1cr0Mg5941bnVbx5imOgI9wDkQNx7Ptmg iJsDoigOx8z+saMCVfCu3L+vYQo+GDWHGKIQAOJUaQ/noWyZ+e15uw8uG5PzsGeJTw clKRHmMO7byJJpMWQ+SsEYfRIAPs8IN8x+ThDtGf3D3FHERF1i6NrXL56QY41nKErk ccC+HrYB4MR2w8IRh18UTXy0DDyPvJz3y+CYlZSyrvVr1awpsIhFfzMvcKZBGSlCPO lz1lBpvqJ5ZYvNPZcWCTjBC4tuHuAOS+SpRL6nrcmGj2u8XDoptvQkZp/GRDh4MqM5 gpy0lLsR5+lpw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4fr9R25nsVz4wbr; Wed, 08 Apr 2026 14:42:38 +1000 (AEST) Date: Wed, 8 Apr 2026 14:42:10 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 10/18] fwd_rule: Move rule conflict checking from fwd_rule_add() to caller Message-ID: References: <20260407031630.2457081-1-david@gibson.dropbear.id.au> <20260407031630.2457081-11-david@gibson.dropbear.id.au> <20260408011450.1ef3fd7c@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YVcb0108P+4PbueW" Content-Disposition: inline In-Reply-To: Message-ID-Hash: DAH4I23XEH42FWTOR4FDER4LGABHQPWG X-Message-ID-Hash: DAH4I23XEH42FWTOR4FDER4LGABHQPWG X-MailFrom: dgibson@gandalf.ozlabs.org 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: 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: --YVcb0108P+4PbueW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 08, 2026 at 11:37:04AM +1000, David Gibson wrote: > On Wed, Apr 08, 2026 at 01:14:50AM +0200, Stefano Brivio wrote: > > On Tue, 7 Apr 2026 13:16:22 +1000 > > David Gibson wrote: [snip] > > Meanwhile, I noticed some warnings that strangely appear only during the > > build of passt.avx2: > >=20 > > cc -Wall -Wextra -Wno-format-zero-length -Wformat-security -pedantic -s= td=3Dc11 -D_XOPEN_SOURCE=3D700 -D_GNU_SOURCE -D_FORTIFY_SOURCE=3D2 -pie -fP= IE -DPAGE_SIZE=3D4096 -DVERSION=3D\"2026_01_20.386b5f5-84-ge87c74f\" -DDUAL= _STACK_SOCKETS=3D1 -DHAS_GETRANDOM -fstack-protector-strong -Ofast -mavx2 -= ftree-vectorize -funroll-loops \ > > arch.c arp.c bitmap.c checksum.c conf.c dhcp.c dhcpv6.c epoll_ctl.c fl= ow.c fwd.c fwd_rule.c icmp.c igmp.c inany.c iov.c ip.c isolation.c lineread= =2Ec log.c mld.c ndp.c netlink.c migrate.c packet.c passt.c pasta.c pcap.c = pif.c repair.c serialise.c tap.c tcp.c tcp_buf.c tcp_splice.c tcp_vu.c udp.= c udp_flow.c udp_vu.c util.c vhost_user.c virtio.c vu_common.c -o passt.avx= 2=20 > > In file included from util.h:22, > > from ip.h:12, > > from fwd_rule.h:16, > > from fwd_rule.c:20: > > fwd_rule.c: In function =E2=80=98fwd_rules_info=E2=80=99: > > fwd_rule.c:86:22: warning: =E2=80=98%s=E2=80=99 directive argument is n= ull [-Wformat-overflow=3D] > > 86 | info(" %s", fwd_rule_fmt(&rules[i], buf, siz= eof(buf))); > > | ^~~~~~~~ > > log.h:31:66: note: in definition of macro =E2=80=98info=E2=80=99 > > 31 | #define info(...) logmsg(true, false, LOG_INFO, = __VA_ARGS__) > > | = ^~~~~~~~~~~ > > fwd_rule.c:86:27: note: format string is defined here > > 86 | info(" %s", fwd_rule_fmt(&rules[i], buf, siz= eof(buf))); > > | ^~ > >=20 > > ...but I don't think I looked at the code changes causing them, yet (and > > didn't bisect the series either). This is with gcc 13.3.0. >=20 > Huh. I don't see those those with gcc 15.2.1. I _think_ it's a false > positive. Investigating... Ok, I think I have a workaround for this. I reproduced the problem, and unsurprisingly it's introduced in patch 7/18 that introduces the new rule formatting helpers. It appears to occur with gcc 12, 13 & 14, but not 15. It's not the AVX2 per-se that triggers it, but the fact we use -Ofast for the passt.avx2 build - it appears to trigger if we go above -O2. The gcc man page does warn that high optimization levels might cause false positives for this warning: -Wformat-overflow=3Dlevel Warn about calls to formatted input/output functions such as "sprintf" and "vsprintf" that might overflow the destination buffer. When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. It's theoretically true that fwd_rule_fmt() can return NULL. However the buffer is sized so that shouldn't ever happen. However gcc seems to think it knows it *is* returning NULL, not just that it could. I'm pretty sure my calculation for the max buffer size is correct. Even if it's not, I'm pretty sure there is a gcc bug in play here: I get the same warning if I replace the guts of fwd_rule_fmt() with an snprintf() of a short fixed string to the output buffer, then check the (now statically known) return value against the buffer size. I _think_ the reason it's occurring here but not the many other places we use a similar pattern (e.g. every inet_ntop() called as a printf argument) is because here the caller is in the same translation unit as fwd_rule_fmt(), so gcc thinks it can look into fwd_rule_fmt() and reason about it, but it's reasoning wrong. In fact, looking closer it seems the problem is triggered when this function is inlined, which I guess it's trying to do on the higher optimization levels. In v2 I've added a ((noinline)) attribute if __GNUC__ < 15, which appears to do the trick. --=20 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 --YVcb0108P+4PbueW Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnV3JUACgkQzQJF27ox 2GcAZQ/+ITrOYuv66mUArsUSclgoBiQxgIcxzyF6mJsv4TdI9UtlgVh5h0KU/8FS t1c8N7SD4/B57pxjKLoaLwlAo6Wz5dOS8CTGJmcJdP6876oNAjalOiqtpfXIqXxf J2DDiCS0bhdQxHAiBUGvYYRmw7k7z6A7MbKB05WhpxnT3lAzqXnhdLu33hSt4FeW g1uX6Vs0zg+3XSOHp8La12qRMGgEbRidwqX7LQgDTD/JP7m1lsjtBCwfRCneKWZW CToK4ZJFE1iD6rvwig/jvHgBQ0NSX8HqFtKmVVIiu2ijZCsRuuWDVtJah1Ne03CU jHXzdoqZyPCGE7Wq44+phJR9Ns4qoB3FPEsfgoy6UQQ9i9EXjLM9dzZGs2/A7hvV G5DCJaFlNOerQB1lqJ0X5YFU7g8REEtKvjnhDqXGVZx5uqXZBO35Seg0HOK1QZXn gVU0+0/nXv2XZt6rtGTQTEQec6R3oFdfJUyuV+vDjhp0xZyL1e1MBXJ00/uQuFyX J/PUopQVZ5iPOz3p8h3AenPvaPhCDElL1inHY2k93m4Q8bwUqgSP2iQb4dR9uuIU zNjCgAhk5OYTTd4faEZwJfcyyCgF+Kihwg8jsrn8gTr9nMkLISxhvBDvdFPgQMyX lQnfuXIj+HsEL+DVAz7T6zQVpG42Ug/i5NFNGjmIFMdd0bbrPwk= =QNTs -----END PGP SIGNATURE----- --YVcb0108P+4PbueW--