fix arm64 build with lack of __cpu_logical_map exported

Commit Message

Greg KH Aug. 8, 2020, 12:42 p.m. UTC

Currently Linus's tree fails with the following build error on arm64
makeallmodconfig:
	ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] undefined!

Seems that kernel.ci also notices this for the past 2 days:
	https://lore.kernel.org/r/[e-mail]
	https://lore.kernel.org/r/[e-mail]

Fix this up by just exporting the symbol.  Don't know if it's the
"right" fix, but it solves the build error for my machines.

Reported-by: "kernelci.org bot" <[e-mail]>
Signed-off-by: Greg Kroah-Hartman <[e-mail]>

Comments

Catalin Marinas Aug. 8, 2020, 3:05 p.m. UTC | #1

Hi Greg,

On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 87e81d29e6fb..b421a4756793 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
>  arch_initcall(reserve_memblock_reserved_regions);
>  
>  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> +EXPORT_SYMBOL_GPL(__cpu_logical_map);

This was still under discussion, Sudeep preferring an alternative in the
driver:

http://lkml.kernel.org/r/20200727172744.GD8003@bogus
http://lkml.kernel.org/r/20200724131059.GB6521@bogus

Sumit came with a new diff inline that fixes the driver instead of
exporting the __cpu_logical_map.

https://lore.kernel.org/linux-arm-kernel/[e-mail]/

Sumit, Sudeep, is the above diff sufficient and can it go upstream?

Thanks.

Greg KH Aug. 8, 2020, 3:29 p.m. UTC | #2

On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> Hi Greg,
> 
> On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 87e81d29e6fb..b421a4756793 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
> >  arch_initcall(reserve_memblock_reserved_regions);
> >  
> >  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> 
> This was still under discussion, Sudeep preferring an alternative in the
> driver:
> 
> http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> 
> Sumit came with a new diff inline that fixes the driver instead of
> exporting the __cpu_logical_map.
> 
> https://lore.kernel.org/linux-arm-kernel/[e-mail]/

Ok, but having a broken tree is not nice, how did this survive
linux-next testing?

> Sumit, Sudeep, is the above diff sufficient and can it go upstream?

Note that MIPS already export this symbol, so perhaps the drivers that
need it on that platform should also be fixed the same way?

thanks,

greg k-h

Catalin Marinas Aug. 8, 2020, 6:29 p.m. UTC | #3

On Sat, Aug 08, 2020 at 05:29:58PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> > On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > index 87e81d29e6fb..b421a4756793 100644
> > > --- a/arch/arm64/kernel/setup.c
> > > +++ b/arch/arm64/kernel/setup.c
> > > @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
> > >  arch_initcall(reserve_memblock_reserved_regions);
> > >  
> > >  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> > 
> > This was still under discussion, Sudeep preferring an alternative in the
> > driver:
> > 
> > http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> > http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> > 
> > Sumit came with a new diff inline that fixes the driver instead of
> > exporting the __cpu_logical_map.
> > 
> > https://lore.kernel.org/linux-arm-kernel/[e-mail]/
> 
> Ok, but having a broken tree is not nice, how did this survive
> linux-next testing?

I guess defconfig worked ok since tegra194-cpufreq is not a module so we
didn't bother much. The fault was reported for allmodconfig but the
discussion didn't conclude.

> > Sumit, Sudeep, is the above diff sufficient and can it go upstream?
> 
> Note that MIPS already export this symbol, so perhaps the drivers that
> need it on that platform should also be fixed the same way?

I push Kefeng's patch to the arm64 for-next/core branch which exports
cpu_logical_map() as a function. We can revert it later is the Tegra
driver is fixed.

I'll send Linus a pull request in a bit, once I finish testing the
branch.

Greg KH Aug. 9, 2020, 7:14 a.m. UTC | #4

On Sat, Aug 08, 2020 at 07:29:08PM +0100, Catalin Marinas wrote:
> On Sat, Aug 08, 2020 at 05:29:58PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> > > On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > > index 87e81d29e6fb..b421a4756793 100644
> > > > --- a/arch/arm64/kernel/setup.c
> > > > +++ b/arch/arm64/kernel/setup.c
> > > > @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
> > > >  arch_initcall(reserve_memblock_reserved_regions);
> > > >  
> > > >  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > > > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> > > 
> > > This was still under discussion, Sudeep preferring an alternative in the
> > > driver:
> > > 
> > > http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> > > http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> > > 
> > > Sumit came with a new diff inline that fixes the driver instead of
> > > exporting the __cpu_logical_map.
> > > 
> > > https://lore.kernel.org/linux-arm-kernel/[e-mail]/
> > 
> > Ok, but having a broken tree is not nice, how did this survive
> > linux-next testing?
> 
> I guess defconfig worked ok since tegra194-cpufreq is not a module so we
> didn't bother much. The fault was reported for allmodconfig but the
> discussion didn't conclude.
> 
> > > Sumit, Sudeep, is the above diff sufficient and can it go upstream?
> > 
> > Note that MIPS already export this symbol, so perhaps the drivers that
> > need it on that platform should also be fixed the same way?
> 
> I push Kefeng's patch to the arm64 for-next/core branch which exports
> cpu_logical_map() as a function. We can revert it later is the Tegra
> driver is fixed.
> 
> I'll send Linus a pull request in a bit, once I finish testing the
> branch.

Thanks, I see it's now in Linus's tree so all should be good.

Now to figure out the arm32 build mess...

greg k-h

Sudeep Holla Aug. 10, 2020, 7:45 a.m. UTC | #5

Hi Catalin,

On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> Hi Greg,
> 
> On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 87e81d29e6fb..b421a4756793 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
> >  arch_initcall(reserve_memblock_reserved_regions);
> >  
> >  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> 
> This was still under discussion, Sudeep preferring an alternative in the
> driver:
> 
> http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> 
> Sumit came with a new diff inline that fixes the driver instead of
> exporting the __cpu_logical_map.
> 
> https://lore.kernel.org/linux-arm-kernel/[e-mail]/
> 
> Sumit, Sudeep, is the above diff sufficient and can it go upstream?
> 

Yes I prefer the above in above thread. I will reply on that thread. Sorry
for missing, been a week.

Patch

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 87e81d29e6fb..b421a4756793 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -275,6 +275,7 @@  static int __init reserve_memblock_reserved_regions(void)
 arch_initcall(reserve_memblock_reserved_regions);
 
 u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+EXPORT_SYMBOL_GPL(__cpu_logical_map);
 
 void __init __no_sanitize_address setup_arch(char **cmdline_p)
 {