On Thu, 2021-05-13 at 09:16 +0800, Baoquan He wrote:

On 05/12/21 at 12:37pm, Mike Rapoport wrote:

quoted

On Wed, May 12, 2021 at 01:33:20PM +0800, Miles Chen wrote:

quoted

On Tue, 2021-05-11 at 13:24 +0300, Mike Rapoport wrote:

quoted

On Tue, May 11, 2021 at 05:31:14PM +0800, Miles Chen wrote:

quoted

In current implementation of node_data, if CONFIG_NEED_MULTIPLE_NODES=y,
node_data is allocated by kzmalloc. If CONFIG_NEED_MULTIPLE_NODES=n,
we use a global variable named "contig_page_data".

If CONFIG_DEBUG_VIRTUAL is not enabled. __pa() can handle both kzalloc and
symbol cases. But if CONFIG_DEBUG_VIRTUAL is set, we will have the
"virt_to_phys used for non-linear address" warning when booting.

Maybe we'll just allocate pgdat for CONFIG_NEED_MULTIPLE_NODES=n (which is
essentially !NUMA) case in, say, free_area_init()?

thanks for your comment.

I check the source tree and found that contig_page_data is used by
crash_core.c as a symbol. I am not familiar with crash_core but I guess
allocate pgdat may break this crash_core users.

For example: some userspace scripts want to read the address of
contig_page_data symbol from a corefile.

kernel/crash_core.c:460:        VMCOREINFO_SYMBOL(contig_page_data);

#ifndef CONFIG_NEED_MULTIPLE_NODES
        VMCOREINFO_SYMBOL(mem_map);
        VMCOREINFO_SYMBOL(contig_page_data);
#endif

My understanding is that VMCOREINFO_SYMBOL() should correspond to actual
symbol. If there is no contig_page_data symbol, there is no need for
VMCOREINFO_SYMBOL() either.

Yeah, it's exported for makedumpfile and crash utility to parse and get
the memory layout of the corrupted kernel. If removing it, makedumpfile
will get it from node_data[]. Looks like a good idea to unify code for
numa|!numa on pglist_data instances.

Add Kazu to CC since he maintain makedumpfile and Crash utilities.

thanks for adding the experts in. (I searched the source code of crash
last night and found that contig_page_data is used in memory.c)

I will move the allocation and initialization to free_area_init() and
submit patch v2.


Miles

My concern is that that only happens on arm/arm64/riscv, does it mean the
warning is not necessary, so can be removed? Or we need to check if
CONFIG_DEBUG_VIRTUAL doesn't work well in this case.

Thanks
Baoquan

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek