[PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

Current version of genksyms doesn't know anything about __typeof_unqual__()
operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
errors when symbols are versioned.

There were no problems with gendwarfksyms.

Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/compiler.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 27725f1ab5ab..98057f93938c 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 /*
  * Use __typeof_unqual__() when available.
  *
- * XXX: Remove test for __CHECKER__ once
- * sparse learns about __typeof_unqual__().
+ * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
+ * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
  */
-#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
+#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
 # define USE_TYPEOF_UNQUAL 1
 #endif
 
-- 
2.49.0

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Paul Menzel]

Dear Uros,


Am 04.04.25 um 12:24 schrieb Uros Bizjak:
> Current version of genksyms doesn't know anything about __typeof_unqual__()
> operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> errors when symbols are versioned.
> 
> There were no problems with gendwarfksyms.
> 
> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
>   include/linux/compiler.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 27725f1ab5ab..98057f93938c 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>   /*
>    * Use __typeof_unqual__() when available.
>    *
> - * XXX: Remove test for __CHECKER__ once
> - * sparse learns about __typeof_unqual__().
> + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
>    */
> -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
>   # define USE_TYPEOF_UNQUAL 1
>   #endif

Thank you for your patch, that fixes my reported issue.

Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # warning `cryptd: no 
symbol version for this_cpu_off is gone`


Kind regards,

Paul

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Masahiro Yamada]

On Fri, Apr 4, 2025 at 7:25 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> Current version of genksyms doesn't know anything about __typeof_unqual__()
> operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> errors when symbols are versioned.
>
> There were no problems with gendwarfksyms.
>
> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---


Why don't you add it to the genksyms keyword table?


diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
index b85e0979a00c..901baf632ed2 100644
--- a/scripts/genksyms/keywords.c
+++ b/scripts/genksyms/keywords.c
@@ -17,6 +17,7 @@ static struct resword {
        { "__signed__", SIGNED_KEYW },
        { "__typeof", TYPEOF_KEYW },
        { "__typeof__", TYPEOF_KEYW },
+       { "__typeof_unqual__", TYPEOF_KEYW },
        { "__volatile", VOLATILE_KEYW },
        { "__volatile__", VOLATILE_KEYW },
        { "__builtin_va_list", VA_LIST_KEYW },






>  include/linux/compiler.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 27725f1ab5ab..98057f93938c 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  /*
>   * Use __typeof_unqual__() when available.
>   *
> - * XXX: Remove test for __CHECKER__ once
> - * sparse learns about __typeof_unqual__().
> + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
>   */
> -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
>  # define USE_TYPEOF_UNQUAL 1
>  #endif
>
> --
> 2.49.0
>
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Fri, Apr 4, 2025 at 2:56 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Fri, Apr 4, 2025 at 7:25 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > errors when symbols are versioned.
> >
> > There were no problems with gendwarfksyms.
> >
> > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > Cc: Sami Tolvanen <samitolvanen@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > ---
>
>
> Why don't you add it to the genksyms keyword table?

It doesn't work, even if I patch it with an even more elaborate patch
(attached).

I guess some more surgery will be needed, but for now a fallback works
as expected.

Uros.

[-- Attachment #2: p.diff.txt --]
[-- Type: text/plain, Size: 761 bytes --]

diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
index b85e0979a00c..8d0167df47ea 100644
--- a/scripts/genksyms/keywords.c
+++ b/scripts/genksyms/keywords.c
@@ -17,6 +17,8 @@ static struct resword {
 	{ "__signed__", SIGNED_KEYW },
 	{ "__typeof", TYPEOF_KEYW },
 	{ "__typeof__", TYPEOF_KEYW },
+	{ "__typeof_unqual", TYPEOF_KEYW },
+	{ "__typeof_unqual__", TYPEOF_KEYW },
 	{ "__volatile", VOLATILE_KEYW },
 	{ "__volatile__", VOLATILE_KEYW },
 	{ "__builtin_va_list", VA_LIST_KEYW },
@@ -57,6 +59,7 @@ static struct resword {
 	{ "struct", STRUCT_KEYW },
 	{ "typedef", TYPEDEF_KEYW },
 	{ "typeof", TYPEOF_KEYW },
+	{ "typeof_unqual", TYPEOF_KEYW },
 	{ "union", UNION_KEYW },
 	{ "unsigned", UNSIGNED_KEYW },
 	{ "void", VOID_KEYW },

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Masahiro Yamada]

On Fri, Apr 4, 2025 at 10:11 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Fri, Apr 4, 2025 at 2:56 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Fri, Apr 4, 2025 at 7:25 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > errors when symbols are versioned.
> > >
> > > There were no problems with gendwarfksyms.
> > >
> > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > ---
> >
> >
> > Why don't you add it to the genksyms keyword table?
>
> It doesn't work, even if I patch it with an even more elaborate patch
> (attached).
>
> I guess some more surgery will be needed, but for now a fallback works
> as expected.
>
> Uros.

The attached patch looks good to me.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahiroy@kernel.org> wrote:

> > > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > > errors when symbols are versioned.
> > > >
> > > > There were no problems with gendwarfksyms.
> > > >
> > > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > >
> > >
> > > Why don't you add it to the genksyms keyword table?
> >
> > It doesn't work, even if I patch it with an even more elaborate patch
> > (attached).
> >
> > I guess some more surgery will be needed, but for now a fallback works
> > as expected.
> >
> > Uros.
>
> The attached patch looks good to me.

FAOD - do you refer to the submitted one for compiler.h or to the one
for scripts/genksyms/keywords.c? (The latter doesn't fix the warning,
though).

Thanks,
Uros.

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Masahiro Yamada]

On Fri, Apr 4, 2025 at 11:37 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> > > > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > > > errors when symbols are versioned.
> > > > >
> > > > > There were no problems with gendwarfksyms.
> > > > >
> > > > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > ---
> > > >
> > > >
> > > > Why don't you add it to the genksyms keyword table?
> > >
> > > It doesn't work, even if I patch it with an even more elaborate patch
> > > (attached).
> > >
> > > I guess some more surgery will be needed, but for now a fallback works
> > > as expected.
> > >
> > > Uros.
> >
> > The attached patch looks good to me.
>
> FAOD - do you refer to the submitted one for compiler.h or to the one
> for scripts/genksyms/keywords.c? (The latter doesn't fix the warning,
> though).



You are still seeing the warnings because __typeof_unqual__
is not only the issue.

Hint:

$ make -s KCFLAGS=-D__GENKSYMS__  arch/x86/kernel/setup_percpu.i
$ grep  'this_cpu_off;'  arch/x86/kernel/setup_percpu.i




--
Best Regards
Masahiro Yamada

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

On Fri, Apr 4, 2025 at 9:14 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Fri, Apr 4, 2025 at 11:37 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > > > > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > > > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > > > > errors when symbols are versioned.
> > > > > >
> > > > > > There were no problems with gendwarfksyms.
> > > > > >
> > > > > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > > > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > > > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > > > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > ---
> > > > >
> > > > >
> > > > > Why don't you add it to the genksyms keyword table?
> > > >
> > > > It doesn't work, even if I patch it with an even more elaborate patch
> > > > (attached).
> > > >
> > > > I guess some more surgery will be needed, but for now a fallback works
> > > > as expected.
> > > >
> > > > Uros.
> > >
> > > The attached patch looks good to me.
> >
> > FAOD - do you refer to the submitted one for compiler.h or to the one
> > for scripts/genksyms/keywords.c? (The latter doesn't fix the warning,
> > though).
>
>
>
> You are still seeing the warnings because __typeof_unqual__
> is not only the issue.
>
> Hint:
>
> $ make -s KCFLAGS=-D__GENKSYMS__  arch/x86/kernel/setup_percpu.i
> $ grep  'this_cpu_off;'  arch/x86/kernel/setup_percpu.i

I see.

With my workaround, this_cpu_off is declared as:

extern __attribute__((section(".data..percpu" "..hot.."
"this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;

while without workaround, the same variable is declared as:

extern __seg_gs __attribute__((section(".data..percpu" "..hot.."
"this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;

It looks that genksyms should be extended to handle (or ignore)
__seg_gs/__seg_fs named address prefix. Somewhat surprising, because
genksyms can process:

extern __attribute__((section(".data..percpu" "..hot.."
"const_current_task"))) __typeof__(struct task_struct * const
__seg_gs) const_current_task

without problems.

I'm sorry, but I'm not able to extend genksyms with a new keyword by myself...

Uros.

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Borislav Petkov]

On Sun, Apr 06, 2025 at 05:36:13PM +0200, Uros Bizjak wrote:
> On Fri, Apr 4, 2025 at 9:14 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Fri, Apr 4, 2025 at 11:37 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > > > > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > > > > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > > > > > errors when symbols are versioned.
> > > > > > >
> > > > > > > There were no problems with gendwarfksyms.
> > > > > > >
> > > > > > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > > > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > > > > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > > > > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > > > > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > > ---
> > > > > >
> > > > > >
> > > > > > Why don't you add it to the genksyms keyword table?
> > > > >
> > > > > It doesn't work, even if I patch it with an even more elaborate patch
> > > > > (attached).
> > > > >
> > > > > I guess some more surgery will be needed, but for now a fallback works
> > > > > as expected.
> > > > >
> > > > > Uros.
> > > >
> > > > The attached patch looks good to me.
> > >
> > > FAOD - do you refer to the submitted one for compiler.h or to the one
> > > for scripts/genksyms/keywords.c? (The latter doesn't fix the warning,
> > > though).
> >
> >
> >
> > You are still seeing the warnings because __typeof_unqual__
> > is not only the issue.
> >
> > Hint:
> >
> > $ make -s KCFLAGS=-D__GENKSYMS__  arch/x86/kernel/setup_percpu.i
> > $ grep  'this_cpu_off;'  arch/x86/kernel/setup_percpu.i
> 
> I see.
> 
> With my workaround, this_cpu_off is declared as:
> 
> extern __attribute__((section(".data..percpu" "..hot.."
> "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
> 
> while without workaround, the same variable is declared as:
> 
> extern __seg_gs __attribute__((section(".data..percpu" "..hot.."
> "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
> 
> It looks that genksyms should be extended to handle (or ignore)
> __seg_gs/__seg_fs named address prefix. Somewhat surprising, because
> genksyms can process:
> 
> extern __attribute__((section(".data..percpu" "..hot.."
> "const_current_task"))) __typeof__(struct task_struct * const
> __seg_gs) const_current_task
> 
> without problems.
> 
> I'm sorry, but I'm not able to extend genksyms with a new keyword by myself...

Well, we need a fix here because this fires a lot by now - triggers on my
machines now too.

So either take a fix or we'll need to revert until it is fixed properly.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

On Wed, Apr 9, 2025 at 5:28 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Sun, Apr 06, 2025 at 05:36:13PM +0200, Uros Bizjak wrote:
> > On Fri, Apr 4, 2025 at 9:14 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Fri, Apr 4, 2025 at 11:37 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > >
> > > > On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > > > > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > > > > > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > > > > > > errors when symbols are versioned.
> > > > > > > >
> > > > > > > > There were no problems with gendwarfksyms.
> > > > > > > >
> > > > > > > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > > > > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > > > > > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > > > > > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > > > > > > Cc: Sami Tolvanen <samitolvanen@google.com>
> > > > > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > > > > ---
> > > > > > >
> > > > > > >
> > > > > > > Why don't you add it to the genksyms keyword table?
> > > > > >
> > > > > > It doesn't work, even if I patch it with an even more elaborate patch
> > > > > > (attached).
> > > > > >
> > > > > > I guess some more surgery will be needed, but for now a fallback works
> > > > > > as expected.
> > > > > >
> > > > > > Uros.
> > > > >
> > > > > The attached patch looks good to me.
> > > >
> > > > FAOD - do you refer to the submitted one for compiler.h or to the one
> > > > for scripts/genksyms/keywords.c? (The latter doesn't fix the warning,
> > > > though).
> > >
> > >
> > >
> > > You are still seeing the warnings because __typeof_unqual__
> > > is not only the issue.
> > >
> > > Hint:
> > >
> > > $ make -s KCFLAGS=-D__GENKSYMS__  arch/x86/kernel/setup_percpu.i
> > > $ grep  'this_cpu_off;'  arch/x86/kernel/setup_percpu.i
> >
> > I see.
> >
> > With my workaround, this_cpu_off is declared as:
> >
> > extern __attribute__((section(".data..percpu" "..hot.."
> > "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
> >
> > while without workaround, the same variable is declared as:
> >
> > extern __seg_gs __attribute__((section(".data..percpu" "..hot.."
> > "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
> >
> > It looks that genksyms should be extended to handle (or ignore)
> > __seg_gs/__seg_fs named address prefix. Somewhat surprising, because
> > genksyms can process:
> >
> > extern __attribute__((section(".data..percpu" "..hot.."
> > "const_current_task"))) __typeof__(struct task_struct * const
> > __seg_gs) const_current_task
> >
> > without problems.
> >
> > I'm sorry, but I'm not able to extend genksyms with a new keyword by myself...
>
> Well, we need a fix here because this fires a lot by now - triggers on my
> machines now too.
>
> So either take a fix or we'll need to revert until it is fixed properly.

The workaround is posted to the list. It should be committed to the
mainline until genksyms is fixed.

Uros.

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Borislav Petkov]

On Wed, Apr 09, 2025 at 05:32:39PM +0200, Uros Bizjak wrote:
> The workaround is posted to the list. It should be committed to the
> mainline until genksyms is fixed.

I'll take it through tip.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

On Wed, Apr 9, 2025 at 5:38 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Apr 09, 2025 at 05:32:39PM +0200, Uros Bizjak wrote:
> > The workaround is posted to the list. It should be committed to the
> > mainline until genksyms is fixed.
>
> I'll take it through tip.

Thanks!

Best regards,
Uros.

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

[tip-bot2 for Uros Bizjak]

The following commit has been merged into the core/urgent branch of tip:

Commit-ID:     e696e5a114b59035f5a889d5484fedec4f40c1f3
Gitweb:        https://git.kernel.org/tip/e696e5a114b59035f5a889d5484fedec4f40c1f3
Author:        Uros Bizjak <ubizjak@gmail.com>
AuthorDate:    Fri, 04 Apr 2025 12:24:37 +02:00
Committer:     Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Thu, 10 Apr 2025 12:44:27 +02:00

compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

Current version of genksyms doesn't know anything about __typeof_unqual__()
operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
errors when symbols are versioned.

There were no problems with gendwarfksyms.

Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20250404102535.705090-1-ubizjak@gmail.com
---
 include/linux/compiler.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 27725f1..98057f9 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 /*
  * Use __typeof_unqual__() when available.
  *
- * XXX: Remove test for __CHECKER__ once
- * sparse learns about __typeof_unqual__().
+ * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
+ * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
  */
-#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
+#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
 # define USE_TYPEOF_UNQUAL 1
 #endif
 

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

[Borislav Petkov]

On Thu, Apr 10, 2025 at 10:58:46AM -0000, tip-bot2 for Uros Bizjak wrote:
> The following commit has been merged into the core/urgent branch of tip:
> 
> Commit-ID:     e696e5a114b59035f5a889d5484fedec4f40c1f3
> Gitweb:        https://git.kernel.org/tip/e696e5a114b59035f5a889d5484fedec4f40c1f3
> Author:        Uros Bizjak <ubizjak@gmail.com>
> AuthorDate:    Fri, 04 Apr 2025 12:24:37 +02:00
> Committer:     Borislav Petkov (AMD) <bp@alien8.de>
> CommitterDate: Thu, 10 Apr 2025 12:44:27 +02:00
> 
> compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined
> 
> Current version of genksyms doesn't know anything about __typeof_unqual__()
> operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> errors when symbols are versioned.
> 
> There were no problems with gendwarfksyms.
> 
> Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Link: https://lore.kernel.org/r/20250404102535.705090-1-ubizjak@gmail.com
> ---
>  include/linux/compiler.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 27725f1..98057f9 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  /*
>   * Use __typeof_unqual__() when available.
>   *
> - * XXX: Remove test for __CHECKER__ once
> - * sparse learns about __typeof_unqual__().
> + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
>   */
> -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
>  # define USE_TYPEOF_UNQUAL 1
>  #endif

So mingo is right - this is not really a fix but a brown-paper bag of
sorts.

The right thing to do here is to unpatch the __typeof_unqual__ stuff
until all the fallout from it - genksyms and whatever else - has been
fixed properly.

So to avoid too much churn I's suggest something like this (totally untested
ofc) until all has been fixed.

---

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 27725f1ab5ab..916a97999ddb 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -232,11 +232,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
  * XXX: Remove test for __CHECKER__ once
  * sparse learns about __typeof_unqual__().
  */
-#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
-# define USE_TYPEOF_UNQUAL 1
-#endif
+#undef USE_TYPEOF_UNQUAL
 
-/*
+	/*
  * Define TYPEOF_UNQUAL() to use __typeof_unqual__() as typeof
  * operator when available, to return an unqualified type of the exp.
  */

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

[Uros Bizjak]

On Fri, Apr 11, 2025 at 11:07 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Thu, Apr 10, 2025 at 10:58:46AM -0000, tip-bot2 for Uros Bizjak wrote:
> > The following commit has been merged into the core/urgent branch of tip:
> >
> > Commit-ID:     e696e5a114b59035f5a889d5484fedec4f40c1f3
> > Gitweb:        https://git.kernel.org/tip/e696e5a114b59035f5a889d5484fedec4f40c1f3
> > Author:        Uros Bizjak <ubizjak@gmail.com>
> > AuthorDate:    Fri, 04 Apr 2025 12:24:37 +02:00
> > Committer:     Borislav Petkov (AMD) <bp@alien8.de>
> > CommitterDate: Thu, 10 Apr 2025 12:44:27 +02:00
> >
> > compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined
> >
> > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > errors when symbols are versioned.
> >
> > There were no problems with gendwarfksyms.
> >
> > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> > Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Link: https://lore.kernel.org/r/20250404102535.705090-1-ubizjak@gmail.com
> > ---
> >  include/linux/compiler.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 27725f1..98057f9 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> >  /*
> >   * Use __typeof_unqual__() when available.
> >   *
> > - * XXX: Remove test for __CHECKER__ once
> > - * sparse learns about __typeof_unqual__().
> > + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> > + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
> >   */
> > -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> > +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
> >  # define USE_TYPEOF_UNQUAL 1
> >  #endif
>
> So mingo is right - this is not really a fix but a brown-paper bag of
> sorts.
>
> The right thing to do here is to unpatch the __typeof_unqual__ stuff
> until all the fallout from it - genksyms and whatever else - has been
> fixed properly.
>
> So to avoid too much churn I's suggest something like this (totally untested
> ofc) until all has been fixed.

FYI, the sparse patch is at [1], but the talk about the abandoned
project suggests that __typeof_unqual__ and dependent percpu checks
will remain disabled for some time.

[1] https://lore.kernel.org/linux-sparse/5b8d0dee-8fb6-45af-ba6c-7f74aff9a4b8@stanley.mountain/

Uros.

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

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Apr 10, 2025 at 10:58:46AM -0000, tip-bot2 for Uros Bizjak wrote:
> > The following commit has been merged into the core/urgent branch of tip:
> > 
> > Commit-ID:     e696e5a114b59035f5a889d5484fedec4f40c1f3
> > Gitweb:        https://git.kernel.org/tip/e696e5a114b59035f5a889d5484fedec4f40c1f3
> > Author:        Uros Bizjak <ubizjak@gmail.com>
> > AuthorDate:    Fri, 04 Apr 2025 12:24:37 +02:00
> > Committer:     Borislav Petkov (AMD) <bp@alien8.de>
> > CommitterDate: Thu, 10 Apr 2025 12:44:27 +02:00
> > 
> > compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined
> > 
> > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > errors when symbols are versioned.
> > 
> > There were no problems with gendwarfksyms.
> > 
> > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> > Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > Link: https://lore.kernel.org/r/20250404102535.705090-1-ubizjak@gmail.com
> > ---
> >  include/linux/compiler.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 27725f1..98057f9 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> >  /*
> >   * Use __typeof_unqual__() when available.
> >   *
> > - * XXX: Remove test for __CHECKER__ once
> > - * sparse learns about __typeof_unqual__().
> > + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> > + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
> >   */
> > -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> > +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
> >  # define USE_TYPEOF_UNQUAL 1
> >  #endif
> 
> So mingo is right - this is not really a fix but a brown-paper bag of
> sorts.

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

Maybe akpm can merge this or some other fix and sort it out? AFAICS the 
bug came in via the -mm tree in January, via:

  ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro")

Thanks,

	Ingo

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

[Uros Bizjak]

On Sat, Apr 12, 2025 at 10:55 AM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Borislav Petkov <bp@alien8.de> wrote:
>
> > On Thu, Apr 10, 2025 at 10:58:46AM -0000, tip-bot2 for Uros Bizjak wrote:
> > > The following commit has been merged into the core/urgent branch of tip:
> > >
> > > Commit-ID:     e696e5a114b59035f5a889d5484fedec4f40c1f3
> > > Gitweb:        https://git.kernel.org/tip/e696e5a114b59035f5a889d5484fedec4f40c1f3
> > > Author:        Uros Bizjak <ubizjak@gmail.com>
> > > AuthorDate:    Fri, 04 Apr 2025 12:24:37 +02:00
> > > Committer:     Borislav Petkov (AMD) <bp@alien8.de>
> > > CommitterDate: Thu, 10 Apr 2025 12:44:27 +02:00
> > >
> > > compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined
> > >
> > > Current version of genksyms doesn't know anything about __typeof_unqual__()
> > > operator.  Avoid the usage of __typeof_unqual__() with genksyms to prevent
> > > errors when symbols are versioned.
> > >
> > > There were no problems with gendwarfksyms.
> > >
> > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
> > > Closes: https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c035@molgen.mpg.de/
> > > Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> > > Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
> > > Link: https://lore.kernel.org/r/20250404102535.705090-1-ubizjak@gmail.com
> > > ---
> > >  include/linux/compiler.h | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > > index 27725f1..98057f9 100644
> > > --- a/include/linux/compiler.h
> > > +++ b/include/linux/compiler.h
> > > @@ -229,10 +229,10 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> > >  /*
> > >   * Use __typeof_unqual__() when available.
> > >   *
> > > - * XXX: Remove test for __CHECKER__ once
> > > - * sparse learns about __typeof_unqual__().
> > > + * XXX: Remove test for __GENKSYMS__ once "genksyms" handles
> > > + * __typeof_unqual__(), and test for __CHECKER__ once "sparse" handles it.
> > >   */
> > > -#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
> > > +#if CC_HAS_TYPEOF_UNQUAL && !defined(__GENKSYMS__) && !defined(__CHECKER__)
> > >  # define USE_TYPEOF_UNQUAL 1
> > >  #endif
> >
> > So mingo is right - this is not really a fix but a brown-paper bag of
> > sorts.
>
> 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. This
functionality was discussed and specifically requested at [1] and [2]
by Thomas [CC'd]:

--q--
Coming back to __percpu. As I mentioned in the original thread it's a sad
state of affairs that the only way to detect the __percpu fails is sparse
or some other static checker:

      https://lore.kernel.org/all/87bk7vuldh.ffs@tglx

But that's a different problem to solve and does not invalidate the fixes
which come with this series in any way.

If the compiler people would have provided a way to utilize the anyway
non-standard name space support in a useful way, I could have spared the
time to bang my head agaist the wall simply because this would have failed
to build in the first place long ago. That just makes me sad.

After wading through this, I really ask the 0-day people to push hard on
any sparse fallout which involves __percpu. The resulting failures can be
truly subtle and not necessarily fatal right away.
--/q--

and

--q--
I did not follow the __set_gs work closely, so I don't know whether Uros
ever tried to actually mark the per CPU variable __set_gs right away,
which would obviously catch the above 'foo' nonsense.

I think this should just work, but that would obviously require to do
the type cast magic at the EXPORT_SYMBOL side and in some other places.
--/q--

[1] https://lore.kernel.org/lkml/20240303235029.555787150@linutronix.de/
[2] https://lore.kernel.org/lkml/87edcruvja.ffs@tglx/

My proposed "workaround" patch (quoted above) will fallback to
generate a preprocessed source that both, sparse and genksyms
understand *without any loss of functionality*. This exact source is
what these tools currently process, and as shown in the message trail,
the proposed patch fully restores the existing functionality.
Effectively, genksyms would generate the same CRC if it would match
typeof_unqual keyword with typeof and ignore __seg_gs keyword.

The effectiveness of the check can be seen in the pull request for MM
updates [3]:

--q--
- The 6 patch series "Enable strict percpu address space checks" from
  Uros Bizjak uses x86 named address space qualifiers to provide
  compile-time checking of percpu area accesses.

  This has caused a small amount of fallout - two or three issues were
  reported.  In all cases the calling[sic] code was founf[sic] to be incorrect.
--/q--

[3] https://lore.kernel.org/lkml/20250330165732.f4c1493615375623f67e38eb@linux-foundation.org/

The patch that disables the above checks trades enablement of this new
functionality for the request that genksyms (and sparse?) fully
support the new keyword first. A workaround was promptly developed
that allows the external tools to work without any loss of
functionality, and allows these tools to be independently improved at
any later time. Please also note that genksyms is already partially
obsoleted by and substituted in allyesconfig by gendwarfksyms, this
was the reason the issue was found only at rc1 time.

Also, I don't think that the issue falls into the "brown-paper bag"
bug category at all. The unfixed source results in a minor loss of
functionality (percpu symbols are not versioned), was detected at rc1
and promptly fixed (worked around). The issue can't be detected by any
standardized approach (allyesconfig compile), and for the core change
of this magnitude, some fall-out is to be expected during integration
(rc1) time. FYI - more than 30 patches were needed to fix percpu
issues in the kernel source (many of these issues were not found by
sparse) before checks were enabled and the enablement was already
postponed for one release to fix an issue, triggered by some extremely
dubious usage by external tools (rust).

Based on the above facts, I'd like to ask maintainers to reconsider
their decision.

Uros.

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

[Ingo Molnar]

* Uros Bizjak <ubizjak@gmail.com> 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?

Thanks,

	Ingo

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@kernel.org> wrote:
>
>
> * Uros Bizjak <ubizjak@gmail.com> 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.

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

[Ingo Molnar]

* Uros Bizjak <ubizjak@gmail.com> wrote:

> On Sun, Apr 13, 2025 at 10:55 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@gmail.com> 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

I did nothing to remove the USE_TYPEOF_UNQUAL definition, did I?

> [...] 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, [...]

I did not remove commit ac053946f5c4, it's already upstream. Nor did I 
advocate for it to be reverted - I'd like it to be fixed. So you are 
barking up the wrong tree.

Thanks,

	Ingo

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

[Uros Bizjak]

On Sun, Apr 13, 2025 at 8:56 PM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Uros Bizjak <ubizjak@gmail.com> wrote:
>
> > On Sun, Apr 13, 2025 at 10:55 AM Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > >
> > > * Uros Bizjak <ubizjak@gmail.com> 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
>
> I did nothing to remove the USE_TYPEOF_UNQUAL definition, did I?

So ... let's slow the ball down a bit. The patch I'm worried about is [1]:

-#if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__)
-# define USE_TYPEOF_UNQUAL 1
-#endif
+#undef USE_TYPEOF_UNQUAL

[1] https://lore.kernel.org/lkml/20250411210815.GAZ_mEv8riLWzvERYY@renoirsky.local/

and in [2] my proposed patch is commented as:

--q--
> So mingo is right - this is not really a fix but a brown-paper bag of
> sorts.

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

Maybe akpm can merge this or some other fix and sort it out? AFAICS the
bug came in via the -mm tree in January, via:

  ac053946f5c4 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
--/q--

[2] https://lore.kernel.org/lkml/Z_oqalk92C4G6Rqt@gmail.com/

> > [...] 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, [...]
>
> I did not remove commit ac053946f5c4, it's already upstream. Nor did I
> advocate for it to be reverted - I'd like it to be fixed. So you are
> barking up the wrong tree.

If the intention is to pass my proposed workaround via Andrew's tree,
then I'm happy to bark up the wrong tree, but from the referred
message trail, I didn't get the clear decision about the patch, and
neither am sure which patch "brown paper bag bug" refers to.

Thanks,
Uros.

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

[Ingo Molnar]

* Uros Bizjak <ubizjak@gmail.com> wrote:

> > > If this commit is removed, [...]
> >
> > I did not remove commit ac053946f5c4, it's already upstream. Nor 
> > did I advocate for it to be reverted - I'd like it to be fixed. So 
> > you are barking up the wrong tree.
> 
> If the intention is to pass my proposed workaround via Andrew's tree, 
> then I'm happy to bark up the wrong tree, but from the referred 
> message trail, I didn't get the clear decision about the patch, and 
> neither am sure which patch "brown paper bag bug" refers to.

It's up to akpm (he merged your original patch that regressed), but I 
think scripts/genksyms/ should be fixed instead of worked around - 
which is why I zapped the workaround.

Thanks,

	Ingo

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

[Uros Bizjak]

On Sun, Apr 13, 2025 at 9:20 PM Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Uros Bizjak <ubizjak@gmail.com> wrote:
>
> > > > If this commit is removed, [...]
> > >
> > > I did not remove commit ac053946f5c4, it's already upstream. Nor
> > > did I advocate for it to be reverted - I'd like it to be fixed. So
> > > you are barking up the wrong tree.
> >
> > If the intention is to pass my proposed workaround via Andrew's tree,
> > then I'm happy to bark up the wrong tree, but from the referred
> > message trail, I didn't get the clear decision about the patch, and
> > neither am sure which patch "brown paper bag bug" refers to.
>
> It's up to akpm (he merged your original patch that regressed), but I
> think scripts/genksyms/ should be fixed instead of worked around -
> which is why I zapped the workaround.

As said earlier, I have tried to fix genksyms, but the simple fix was
not enough. The correct fix would be somehow more involved, and I have
zero experience in genksyms source. I'm afraid I don't know this
source well enough to offer a fix in the foreseeable future, so I
resorted to the workaround (which at the end of the day is as
effective as the real fix).

Regards,
Uros.

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

[Ingo Molnar]

* Uros Bizjak <ubizjak@gmail.com> wrote:

> On Sun, Apr 13, 2025 at 9:20 PM Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > > > > If this commit is removed, [...]
> > > >
> > > > I did not remove commit ac053946f5c4, it's already upstream. Nor
> > > > did I advocate for it to be reverted - I'd like it to be fixed. So
> > > > you are barking up the wrong tree.
> > >
> > > If the intention is to pass my proposed workaround via Andrew's tree,
> > > then I'm happy to bark up the wrong tree, but from the referred
> > > message trail, I didn't get the clear decision about the patch, and
> > > neither am sure which patch "brown paper bag bug" refers to.
> >
> > It's up to akpm (he merged your original patch that regressed), but I
> > think scripts/genksyms/ should be fixed instead of worked around -
> > which is why I zapped the workaround.
> 
> As said earlier, I have tried to fix genksyms, but the simple fix was 
> not enough. The correct fix would be somehow more involved, and I 
> have zero experience in genksyms source. I'm afraid I don't know this 
> source well enough to offer a fix in the foreseeable future, so I 
> resorted to the workaround (which at the end of the day is as 
> effective as the real fix).

I disagree that hacks/workarounds are as effective as the real fix.

In the Linux kernel the usual principle is that developers who 
introduce unanticipated in-tree regressions are expected to fix them 
for real and not just work them around. Not following that principle 
may have reputational costs going forward (or not), but it's your time 
and your call really.

Thanks,

	Ingo

Re: [PATCH] compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On Sun, Apr 6, 2025 at 5:36 PM Uros Bizjak <ubizjak@gmail.com> wrote:

> > You are still seeing the warnings because __typeof_unqual__
> > is not only the issue.
> >
> > Hint:
> >
> > $ make -s KCFLAGS=-D__GENKSYMS__  arch/x86/kernel/setup_percpu.i
> > $ grep  'this_cpu_off;'  arch/x86/kernel/setup_percpu.i
>
> I see.
>
> With my workaround, this_cpu_off is declared as:
>
> extern __attribute__((section(".data..percpu" "..hot.."
> "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
>
> while without workaround, the same variable is declared as:
>
> extern __seg_gs __attribute__((section(".data..percpu" "..hot.."
> "this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
>
> It looks that genksyms should be extended to handle (or ignore)
> __seg_gs/__seg_fs named address prefix. Somewhat surprising, because
> genksyms can process:
>
> extern __attribute__((section(".data..percpu" "..hot.."
> "const_current_task"))) __typeof__(struct task_struct * const
> __seg_gs) const_current_task
>
> without problems.
>
> I'm sorry, but I'm not able to extend genksyms with a new keyword by myself...

The following patch that handles typeof_unqual() as typeof(), and in
addition ignores __seg_gs similar to how other type qualifiers are
ignored, avoids genksyms errors.

Uros.

[-- Attachment #2: p.diff.txt --]
[-- Type: text/plain, Size: 1633 bytes --]

diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
index b85e0979a00c..ee1499d27061 100644
--- a/scripts/genksyms/keywords.c
+++ b/scripts/genksyms/keywords.c
@@ -17,6 +17,8 @@ static struct resword {
 	{ "__signed__", SIGNED_KEYW },
 	{ "__typeof", TYPEOF_KEYW },
 	{ "__typeof__", TYPEOF_KEYW },
+	{ "__typeof_unqual", TYPEOF_KEYW },
+	{ "__typeof_unqual__", TYPEOF_KEYW },
 	{ "__volatile", VOLATILE_KEYW },
 	{ "__volatile__", VOLATILE_KEYW },
 	{ "__builtin_va_list", VA_LIST_KEYW },
@@ -40,6 +42,10 @@ static struct resword {
 	// KAO. },
 	// { "attribute", ATTRIBUTE_KEYW },
 
+	// X86 named address space qualifiers
+	{ "__seg_gs", X86_SEG_KEYW },
+	{ "__seg_fs", X86_SEG_KEYW },
+
 	{ "auto", AUTO_KEYW },
 	{ "char", CHAR_KEYW },
 	{ "const", CONST_KEYW },
@@ -57,6 +63,7 @@ static struct resword {
 	{ "struct", STRUCT_KEYW },
 	{ "typedef", TYPEDEF_KEYW },
 	{ "typeof", TYPEOF_KEYW },
+	{ "typeof_unqual", TYPEOF_KEYW },
 	{ "union", UNION_KEYW },
 	{ "unsigned", UNSIGNED_KEYW },
 	{ "void", VOID_KEYW },
diff --git a/scripts/genksyms/parse.y b/scripts/genksyms/parse.y
index ee600a804fa1..efdcf07c4eb6 100644
--- a/scripts/genksyms/parse.y
+++ b/scripts/genksyms/parse.y
@@ -91,6 +91,8 @@ static void record_compound(struct string_list **keyw,
 %token TYPEOF_KEYW
 %token VA_LIST_KEYW
 
+%token X86_SEG_KEYW
+
 %token EXPORT_SYMBOL_KEYW
 
 %token ASM_PHRASE
@@ -292,7 +294,8 @@ type_qualifier_seq:
 	;
 
 type_qualifier:
-	CONST_KEYW | VOLATILE_KEYW
+	X86_SEG_KEYW
+	| CONST_KEYW | VOLATILE_KEYW
 	| RESTRICT_KEYW
 		{ /* restrict has no effect in prototypes so ignore it */
 		  remove_node($1);

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

[Andrew Morton]

On Sun, 13 Apr 2025 21:20:00 +0200 Ingo Molnar <mingo@kernel.org> wrote:

> > > > If this commit is removed, [...]
> > >
> > > I did not remove commit ac053946f5c4, it's already upstream. Nor 
> > > did I advocate for it to be reverted - I'd like it to be fixed. So 
> > > you are barking up the wrong tree.
> > 
> > If the intention is to pass my proposed workaround via Andrew's tree, 
> > then I'm happy to bark up the wrong tree, but from the referred 
> > message trail, I didn't get the clear decision about the patch, and 
> > neither am sure which patch "brown paper bag bug" refers to.
> 
> It's up to akpm (he merged your original patch that regressed), but I 
> think scripts/genksyms/ should be fixed instead of worked around - 
> which is why I zapped the workaround.

I'm OK with the original workaround - super simple and fixes the issue.
I don't know if Borislav intends to upstream this, so I'll grab a copy
also.

Nobody has commented on Uros's more recent alteration to genksyms
(https://lkml.kernel.org/r/CAFULd4aLMF_2AbUAvpYw+o1qo6U-Ya_+Ewy-wW17g-r-MBF9_g@mail.gmail.com)?

Uros, please persist with that approach and hopefully we'll have a
patch which removes the temporary workaround.

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

[Uros Bizjak]

On Tue, Apr 15, 2025 at 3:20 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Sun, 13 Apr 2025 21:20:00 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> > > > > If this commit is removed, [...]
> > > >
> > > > I did not remove commit ac053946f5c4, it's already upstream. Nor
> > > > did I advocate for it to be reverted - I'd like it to be fixed. So
> > > > you are barking up the wrong tree.
> > >
> > > If the intention is to pass my proposed workaround via Andrew's tree,
> > > then I'm happy to bark up the wrong tree, but from the referred
> > > message trail, I didn't get the clear decision about the patch, and
> > > neither am sure which patch "brown paper bag bug" refers to.
> >
> > It's up to akpm (he merged your original patch that regressed), but I
> > think scripts/genksyms/ should be fixed instead of worked around -
> > which is why I zapped the workaround.
>
> I'm OK with the original workaround - super simple and fixes the issue.
> I don't know if Borislav intends to upstream this, so I'll grab a copy
> also.
>
> Nobody has commented on Uros's more recent alteration to genksyms
> (https://lkml.kernel.org/r/CAFULd4aLMF_2AbUAvpYw+o1qo6U-Ya_+Ewy-wW17g-r-MBF9_g@mail.gmail.com)?
>
> Uros, please persist with that approach and hopefully we'll have a
> patch which removes the temporary workaround.

The genksyms patch was posted as formal patch submission at [1] and
was accepted to -tip tree. The genksyms patch obsoletes compiler.h
patch [2], so there is no need for compiler.h change anymore.

[1] https://lore.kernel.org/lkml/20250413220749.270704-1-ubizjak@gmail.com/
[2] https://lore.kernel.org/all/CAFULd4aLMF_2AbUAvpYw+o1qo6U-Ya_+Ewy-wW17g-r-MBF9_g@mail.gmail.com/

Thanks,
Uros.