On Wed, Apr 9, 2025 at 5:28 PM Borislav Petkov <b...@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 <masahi...@kernel.org> wrote:
> > >
> > > On Fri, Apr 4, 2025 at 11:37 PM Uros Bizjak <ubiz...@gmail.com> wrote:
> > > >
> > > > On Fri, Apr 4, 2025 at 4:06 PM Masahiro Yamada <masahi...@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 <ubiz...@gmail.com>
> > > > > > > > Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() 
> > > > > > > > macro")
> > > > > > > > Reported-by: Paul Menzel <pmen...@molgen.mpg.de>
> > > > > > > > Closes: 
> > > > > > > > https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c...@molgen.mpg.de/
> > > > > > > > Cc: Sami Tolvanen <samitolva...@google.com>
> > > > > > > > Cc: Andrew Morton <a...@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.

Reply via email to