passt, branch 2022_09_29.06aa26f

Makefile: Hack for optimised-away store in ndp() before checksum calculation

2022-09-29T10:23:11+00:00

With gcc 11 and 12, passing -flto, or -flto=auto, and -O2,
intra-procedural optimisation gets rid of a fundamental bit in ndp():
the store of hop_limit in the IPv6 header, before the checksum is
calculated, which on x86_64 looks like this:

	ip6hr->hop_limit = IPPROTO_ICMPV6;
    b8c0:	c6 44 24 35 3a       	movb   $0x3a,0x35(%rsp)

Here, hop_limit is temporarily set to the protocol number, to
conveniently get the IPv6 pseudo-header for ICMPv6 checksum
calculation in memory.

With LTO, the assignment just disappears from the binary.

This is rather visible as NDP messages get a wrong checksum, namely
the expected checksum plus 58, and they're ignored by the guest or
in the namespace, meaning we can't get any IPv6 routes, as reported
by Wenli Quan.

The issue affects a significant number of distribution builds,
including the ones for CentOS Stream 9, EPEL 9, Fedora >= 35,
Mageia Cauldron, and openSUSE Tumbleweed.

As a quick workaround, declare csum_unaligned() as "noipa" for gcc
11 and 12, with -flto and -O2. This disables inlining and cloning,
which causes the assignment to be compiled again.

Leave a TODO item: we should figure out if a gcc issue has already
been reported, and report one otherwise. There's no apparent
justification as to why the store could go away.

Reported-by: Wenli Quan 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2129713
Signed-off-by: Stefano Brivio

udp: Replace pragma to ignore bogus stringop-overread warning with workaround

2022-09-29T10:23:10+00:00

Commit c318ffcb4c93 ("udp: Ignore bogus -Wstringop-overread for
write() from gcc 12.1") uses a gcc pragma to ignore a bogus warning,
which started appearing on gcc 12.1 (aarch64 and x86_64) due to:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483

...but gcc 12.2 has the same issue. Not just that: if LTO is enabled,
the pragma itself is ignored (this wasn't the case with gcc 12.1),
because of:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922

Drop the pragma, and assign a frame (in the networking sense) pointer
from the offset of the Ethernet header in the buffer, then pass it to
write() and pcap(), so that gcc doesn't obsess anymore with the fact
that an Ethernet header is 14 bytes and we're sending more than that.

Signed-off-by: Stefano Brivio

Makefile: Extend noinline workarounds for LTO and -O2 to gcc 12

2022-09-29T10:23:07+00:00

Commit 1a563a0cbd49 ("passt: Address gcc 11 warnings") works around an
issue where the remote address passed to hash functions is seen as
uninitialised by gcc, with -flto and -O2.

It turns out we get the same exact behaviour on gcc 12.1 and 12.2, so
extend the applicability of the same workaround to gcc 12.

Don't go further than that, though: should the issue reported at:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
happen to be fixed in a later version of gcc, we won't need the
noinline attributes anymore. Otherwise, we'll notice.

Signed-off-by: Stefano Brivio

cppcheck: Remove unused unmatchedSuppression suppressions

2022-09-29T10:23:05+00:00

It's unclear what original suppressions these unmatchedSuppression
suppressions were supposed to go with.  They don't trigger any warnings on
the current code that I can tell, so remove them.  If we find a problem
with some cppcheck versions in future, replace them with inline
suppressions so it's clearer exactly where the issue is originating.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

Mark unused functions for cppcheck

2022-09-29T10:23:03+00:00

We have a couple of functions that are unused (for now) by design.
Although at least one has a flag so that gcc doesn't warn, cppcheck has its
own warnings about this.  Add specific inline suppressions for these rather
than a blanket suppression in the Makefile.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

cppcheck: Remove unused va_list_usedBeforeStarted suppression

2022-09-29T10:23:01+00:00

I can't get this warning to trigger, even without the suppression, so
remove it.  If it shows up again on some cppcheck version, we can replace
it with inline suppressions so it's clear where the issue lay.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

cppcheck: Remove unused objectIndex suppressions

2022-09-29T10:22:57+00:00

I can't get these warnings to trigger on the cppcheck versions I have, so
remove them.  If we find in future we need to replace these, they should be
replaced with inline suppressions so its clear what's the section of code
at issue.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

cppcheck: Remove unused knownConditionTrueFalse suppression

2022-09-29T10:22:54+00:00

I can't get this warning to trigger, so I think this suppression must be
out of date.  Whether that's because we've changed our code to no longer
have the problem, or because cppcheck itself has been updated to remove a
false positive I don't know.

If we find that we do need a suppression like this for some cppcheck
version, we should replace it with an inline suppression so it's clear
what exactly is triggering the warning.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

cppcheck: Avoid errors due to zeroes in bitwise ORs

2022-09-29T10:22:37+00:00

Recent versions of cppcheck give warnings if using a bitwise OR (|) where
some of the arguments are zero.  We're triggering these warnings in our
generated seccomp.h header, because BPF_LD and BPF_W are zero-valued.
However putting these defines in makes the generate code clearer, even
though they could be left out without changing the values.  So, add
cppcheck suppressions to the generated code.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

Regenerate seccomp.h if seccomp.sh changes

2022-09-29T10:22:34+00:00

seccomp.sh generates seccomp.h, so if we change it, we should re-build
seccomp.h as well.  Add this to the make dependencies so it happens.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio