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

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.

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