All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miles Chen <miles.chen@mediatek.com>
To: Baoquan He <bhe@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<k-hagio-ab@nec.com>
Subject: Re: [PATCH] mm/sparse: fix check_usemap_section_nr warnings
Date: Thu, 13 May 2021 10:53:21 +0800	[thread overview]
Message-ID: <1620874401.21092.10.camel@mtkswgap22> (raw)
In-Reply-To: <20210513011648.GA6776@MiWiFi-R3L-srv>

On Thu, 2021-05-13 at 09:16 +0800, Baoquan He wrote:
> On 05/12/21 at 12:37pm, Mike Rapoport wrote:
> > On Wed, May 12, 2021 at 01:33:20PM +0800, Miles Chen wrote:
> > > On Tue, 2021-05-11 at 13:24 +0300, Mike Rapoport wrote:
> > > > On Tue, May 11, 2021 at 05:31:14PM +0800, Miles Chen wrote:
> > > > > 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

WARNING: multiple messages have this Message-ID (diff)
From: Miles Chen <miles.chen@mediatek.com>
To: Baoquan He <bhe@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<k-hagio-ab@nec.com>
Subject: Re: [PATCH] mm/sparse: fix check_usemap_section_nr warnings
Date: Thu, 13 May 2021 10:53:21 +0800	[thread overview]
Message-ID: <1620874401.21092.10.camel@mtkswgap22> (raw)
In-Reply-To: <20210513011648.GA6776@MiWiFi-R3L-srv>

On Thu, 2021-05-13 at 09:16 +0800, Baoquan He wrote:
> On 05/12/21 at 12:37pm, Mike Rapoport wrote:
> > On Wed, May 12, 2021 at 01:33:20PM +0800, Miles Chen wrote:
> > > On Tue, 2021-05-11 at 13:24 +0300, Mike Rapoport wrote:
> > > > On Tue, May 11, 2021 at 05:31:14PM +0800, Miles Chen wrote:
> > > > > 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
> 


  reply	other threads:[~2021-05-13  2:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11  9:31 [PATCH] mm/sparse: fix check_usemap_section_nr warnings Miles Chen
2021-05-11  9:31 ` Miles Chen
2021-05-11 10:24 ` Mike Rapoport
2021-05-11 10:24   ` Mike Rapoport
2021-05-12  5:33   ` Miles Chen
2021-05-12  5:33     ` Miles Chen
2021-05-12  9:37     ` Mike Rapoport
2021-05-12  9:37       ` Mike Rapoport
2021-05-13  1:16       ` Baoquan He
2021-05-13  1:16         ` Baoquan He
2021-05-13  2:53         ` Miles Chen [this message]
2021-05-13  2:53           ` Miles Chen
2021-05-19  5:30 ` Mike Rapoport
2021-05-19  5:30   ` Mike Rapoport
2021-05-19  7:18   ` Miles Chen
2021-05-19  7:18     ` Miles Chen
2021-05-19  7:56     ` Mike Rapoport
2021-05-19  7:56       ` Mike Rapoport
2021-05-19  8:32       ` Miles Chen
2021-05-19  8:32         ` Miles Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1620874401.21092.10.camel@mtkswgap22 \
    --to=miles.chen@mediatek.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=k-hagio-ab@nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=wsd_upstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.