diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2022-09-29 10:59:38 +0200 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2022-09-29 12:23:11 +0200 |
commit | 06aa26fcf398f5d19ab46e42996190d7f95e837a (patch) | |
tree | cb89e4a0adad24b16b1693b7d8675f8e2bacc8e3 /tcp_splice.c | |
parent | 5290b6f13e493b3fc814b4dc7fac2b5d7c252245 (diff) | |
download | passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar.gz passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar.bz2 passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar.lz passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar.xz passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.tar.zst passt-06aa26fcf398f5d19ab46e42996190d7f95e837a.zip |
Makefile: Hack for optimised-away store in ndp() before checksum calculation2022_09_29.06aa26f
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 <wquan@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2129713
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'tcp_splice.c')
0 files changed, 0 insertions, 0 deletions