On Fri, Jun 6, 2025 at 2:27 AM Uros Bizjak <[email protected]> wrote: > > On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <[email protected]> wrote: > > > > On 05. 06. 25, 19:31, Uros Bizjak wrote: > > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <[email protected]> wrote: > > >> > > >> On 6/5/25 07:27, Jiri Slaby wrote: > > >>> Reverting this gives me back to normal sizes. > > >>> > > >>> Any ideas? > > >> > > >> I don't see any reason not to revert it. The benefits weren't exactly > > >> clear from the changelogs or cover letter. Enabling "various compiler > > >> checks" doesn't exactly scream that this is critical to end users in > > >> some way. > > >> > > >> The only question is if we revert just this last patch or the whole > > >> series. > > >> > > >> Uros, is there an alternative to reverting? > > > > > > This functionality can easily be disabled in include/linux/compiler.h > > > by not defining USE_TYPEOF_UNQUAL: > > > > > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > > > # define USE_TYPEOF_UNQUAL 1 > > > #endif > > > > > > (support for typeof_unqual keyword is required to handle __seg_gs > > > qualifiers), but ... > > > > > > ... the issue is reportedly fixed, please see [1], and ... > > > > Confirmed, I need a patched userspace (libbpf). > > > > > ... you will disable much sought of feature, just ask tglx (and please > > > read his rant at [2]): > > > > Given this is the second time I hit a bug with this, perhaps introduce > > an EXPERIMENTAL CONFIG option, so that random users can simply disable > > it if an issue occurs? Without the need of patching random userspace and > > changing random kernel headers? > > In both cases, the patch *exposed* a bug in a related utility > software, it is not that the patch itself is buggy. IMO, waving off > the issue by disabling the feature you just risk the bug in the > related software to hit even harder in some not too distant future.
The typeof_unqual exposed the issue in the way GCC generates dwarf. The libbpf/pahole is a workaround for incorrect dwarf. The compiler shouldn't emit two identical dwarf definition for one underlying type within one compilation unit. In this case typeof_unqual somehow confused gcc.
