Re: [tip: core/urgent] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

On Sun, Apr 13, 2025 at 10:55 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
>
> * Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
>
> > > Yeah, agreed, I've removed this workaround from tip:core/urgent for
> > > the time being - it's not like genksyms is some magic external
> > > entity we have to work around, it's an in-kernel tool that can be
> > > fixed/enhanced in scripts/genksyms/.
> >
> > Please note that you will disable a check that is finally able to
> > fail the build for a whole class of very subtle percpu bugs.
>
> I simply zapped a commit that was applied two days ago and asked akpm
> to resolve a regression that was introduced upstream via his tree
> through this commit, in this merge window:
>
>   ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
>
> What 'disabled checks' are you talking about?

Percpu checks require TYPEOF_UNQUAL() macro, so removing
USE_TYPEOF_UNQUAL definition will skip the definition of __percpu_qual
in arch/x86/include/asm/percpu.h (please  see
6a367577153acd9b432a5340fb10891eeb7e10f1), and consequently __percpu
macro won't be defined with __seg_gs (please see
6cea5ae714ba47ea4807d15903baca9857a450e6).

If this commit is removed, then the compiler will fallback to old
declarations of percpu variables and won't perform percpu checks
anymore. This new functionality is implemented in such a way that can
be fully disabled in a couple of places, and not declaring
USE_TYPEOF_UNQUAL is one of them.

OTOH, my patch avoids __typeof_unqual__() only when generating
preprocessed source for genksyms. genksyms uses this preprocessed
source to generate CRC32 from keywords that declare variables and it
is perfectly OK to use "old" definitions, without __typeof_unqual__
and __seg_gs keywords; there is no loss of functionality. __GENKSYMS__
condition can be removed once genksyms recognizes __typeof_unqual__
(and __seg_gs).

Everything else besides "sparse", which already uses the same
fallback, handles __typeof_unqual__() perfectly well. This includes
GNUC >= 14 and clang >= 19.

Thanks,
Uros.