On Fri, Jun 6, 2025 at 6:39 PM Alexei Starovoitov
[off-list ref] wrote:

On Fri, Jun 6, 2025 at 2:27 AM Uros Bizjak [off-list ref] wrote:

quoted

On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby [off-list ref] wrote:

quoted

On 05. 06. 25, 19:31, Uros Bizjak wrote:

quoted

On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen [off-list ref] wrote:

quoted

On 6/5/25 07:27, Jiri Slaby wrote:

quoted

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).

quoted

... 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.

Can you please file a bugreport in GCC bugzilla, so we can analyze the issue?

Uros.