Message ID | 20250404102535.705090-1-ubizjak@gmail.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | compiler.h: Avoid the usage of __typeof_unqual__() when __GENKSYMS__ is defined | expand |
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
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 > >
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. 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 },
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.
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.
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
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.
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.
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.
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.
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.
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. 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);
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
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(-)