netdev - Re: linux-next failing build due to missing cubictcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87lf8rf29e.fsf@oldenburg.str.redhat.com>
Date:   Fri, 07 May 2021 09:10:05 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Jiri Slaby <jirislaby@...nel.org>
Cc:     Michal Suchánek <msuchanek@...e.de>,
        Jiri Olsa <jolsa@...hat.com>, Yonghong Song <yhs@...com>,
        linux-kernel@...r.kernel.org, Martin KaFai Lau <kafai@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Song Liu <songliubraving@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Jiri Olsa <jolsa@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>
Subject: Re: linux-next failing build due to missing cubictcp_state symbol

* Jiri Slaby:

> The dot makes the difference, of course. The question is why is it
> there? I keep looking into it. Only if someone has an immediate
> idea...

We see the failure on aarch64 as well, with 8404c9fbc84b741
(from Linus' tree).

As far as I can tell, the core issue is that BTF_ID is applied to a
symbol which is defined as static on the C side (and even in a different
translation unit, but this aspect doesn't really matter).  The compiler
can and will change symbol names, calling conventions and data layout
for static functions/variables, so this is never going to work reliably.
It is possible to inhibit these optimizations by using __attribute__
((used)).  But I'm pretty sure that BTF generation fails to work
properly if there are symbol name collisions, so I think it's better to
drop the static and rely on duplicate symbol checks from the linker
(which of course does not happen for C entities declared static).

Thanks,
Florian