Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors
on arch/microblaze/ and arch/ia64/: (e.g.)
ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
ERROR: "max_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined!
ERROR: "min_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined!
ERROR: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined!
ERROR: "max_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined!
ERROR: "max_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined!
ERROR: "min_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined!
ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined!
ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined!
ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined!
ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined!
ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined!
ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined!
In both arches, these variables are referenced in
arch/$ARCH/include/asm/page.h.
Mike had/has an alternate patch for Microblaze:
https://lore.kernel.org/lkml/[email protected]/
David suggested just exporting min_low_pfn & max_low_pfn in
mm/memblock.c:
https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2006291911220.1118534@chino.kir.corp.google.com/
Reported-by: kernel test robot <[email protected]>
Suggested-by: David Rientjes <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Cc: [email protected]
Cc: Andrew Morton <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: [email protected]
---
mm/memblock.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20200825.orig/mm/memblock.c
+++ linux-next-20200825/mm/memblock.c
@@ -99,6 +99,8 @@ EXPORT_SYMBOL(contig_page_data);
unsigned long max_low_pfn;
unsigned long min_low_pfn;
+EXPORT_SYMBOL(min_low_pfn);
+EXPORT_SYMBOL(max_low_pfn);
unsigned long max_pfn;
unsigned long long max_possible_pfn;
On Fri, Aug 28, 2020 at 05:01:39PM -0700, Randy Dunlap wrote:
> Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors
> on arch/microblaze/ and arch/ia64/: (e.g.)
Please don't. This would give driver developers a wrong impression that
these variables can be used to query memory boundaries, but this is not
the case, at least not on all architectures.
I would prefer fixing it up locally for microblaze and ia64.
> ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
> ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined!
> ERROR: "max_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined!
> ERROR: "min_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined!
> ERROR: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined!
> ERROR: "max_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined!
> ERROR: "max_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined!
> ERROR: "min_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined!
> ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
> ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
> ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined!
> ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined!
> ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined!
> ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined!
> ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined!
> ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined!
>
> In both arches, these variables are referenced in
> arch/$ARCH/include/asm/page.h.
>
> Mike had/has an alternate patch for Microblaze:
> https://lore.kernel.org/lkml/[email protected]/
>
> David suggested just exporting min_low_pfn & max_low_pfn in
> mm/memblock.c:
> https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2006291911220.1118534@chino.kir.corp.google.com/
>
> Reported-by: kernel test robot <[email protected]>
> Suggested-by: David Rientjes <[email protected]>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: [email protected]
> Cc: Andrew Morton <[email protected]>
> Cc: David Rientjes <[email protected]>
> Cc: Mike Rapoport <[email protected]>
> Cc: Michal Simek <[email protected]>
> Cc: Michal Simek <[email protected]>
> Cc: Tony Luck <[email protected]>
> Cc: Fenghua Yu <[email protected]>
> Cc: [email protected]
> ---
> mm/memblock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-next-20200825.orig/mm/memblock.c
> +++ linux-next-20200825/mm/memblock.c
> @@ -99,6 +99,8 @@ EXPORT_SYMBOL(contig_page_data);
>
> unsigned long max_low_pfn;
> unsigned long min_low_pfn;
> +EXPORT_SYMBOL(min_low_pfn);
> +EXPORT_SYMBOL(max_low_pfn);
> unsigned long max_pfn;
> unsigned long long max_possible_pfn;
>
--
Sincerely yours,
Mike.
On 8/29/20 6:04 AM, Mike Rapoport wrote:
> On Fri, Aug 28, 2020 at 05:01:39PM -0700, Randy Dunlap wrote:
>> Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors
>> on arch/microblaze/ and arch/ia64/: (e.g.)
>
> Please don't. This would give driver developers a wrong impression that
> these variables can be used to query memory boundaries, but this is not
> the case, at least not on all architectures.
>
> I would prefer fixing it up locally for microblaze and ia64.
I did that.
and that's why this is labeled as an ALTERNATE PATCH.
thanks.
--
~Randy
Hi Randy,
On Sat, Aug 29, 2020 at 08:40:51AM -0700, Randy Dunlap wrote:
> On 8/29/20 6:04 AM, Mike Rapoport wrote:
> > On Fri, Aug 28, 2020 at 05:01:39PM -0700, Randy Dunlap wrote:
> >> Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors
> >> on arch/microblaze/ and arch/ia64/: (e.g.)
> >
> > Please don't. This would give driver developers a wrong impression that
> > these variables can be used to query memory boundaries, but this is not
> > the case, at least not on all architectures.
> >
> > I would prefer fixing it up locally for microblaze and ia64.
>
> I did that.
> and that's why this is labeled as an ALTERNATE PATCH.
I've seen that, I just wanted to make sure that Andrew wouldn't pick
this one :)
I can help with taking microblaze and ia64 patches via memblock tree
once we have Acks from the arch maintainers.
> thanks.
> --
> ~Randy
>
--
Sincerely yours,
Mike.