passt/Makefile, 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

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

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

cppcheck: Remove localtime suppression for pcap.c

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

Since bf95322f "conf: Make the argument to --pcap option mandatory" we
no longer call localtime() in pcap.c, so we no longer need the matching
cppcheck suppression.

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

cppcheck: Broaden suppression for unused struct members

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

In a number of places in passt we use structures to represent over the wire
or in-file data with a fixed layout.  After initialization we don't access
the fields individually and just write the structure as a whole to its
destination.

Unfortunately cppcheck doesn't cope with this pattern and thinks all the
structure members are unused.  We already have suppressions for this in
pcap.c and dhcp.c   However, it also appears in dhcp.c and netlink.c at
least.  Since this is likely to be common, it seems wiser to just suppress
the error globally.

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