Re: Large modules with 6.15 [was: [PATCH v4 6/6] percpu/x86: Enable strict percpu checks via named AS qualifiers]

[Uros Bizjak <ubizjak@gmail.com>]

On Fri, Jun 6, 2025 at 6:39 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Jun 6, 2025 at 2:27 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > >
> > > On 05. 06. 25, 19:31, Uros Bizjak wrote:
> > > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> 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.

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

Uros.