All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.com,
	richardw.yang@linux.intel.com, dan.j.williams@intel.com,
	osalvador@suse.de, rppt@linux.ibm.com
Subject: Re: [PATCH v3 1/7] mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case
Date: Mon, 9 Mar 2020 09:58:29 +0100	[thread overview]
Message-ID: <b0ff37b3-bae1-bdd6-8a4f-62f03e028839@redhat.com> (raw)
In-Reply-To: <20200307084229.28251-2-bhe@redhat.com>

On 07.03.20 09:42, Baoquan He wrote:
> In section_deactivate(), pfn_to_page() doesn't work any more after
> ms->section_mem_map is resetting to NULL in SPARSEMEM|!VMEMMAP case.
> It caused hot remove failure:
> 
> kernel BUG at mm/page_alloc.c:4806!
> invalid opcode: 0000 [#1] SMP PTI
> CPU: 3 PID: 8 Comm: kworker/u16:0 Tainted: G        W         5.5.0-next-20200205+ #340
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
> Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> RIP: 0010:free_pages+0x85/0xa0
> Call Trace:
>  __remove_pages+0x99/0xc0
>  arch_remove_memory+0x23/0x4d
>  try_remove_memory+0xc8/0x130
>  ? walk_memory_blocks+0x72/0xa0
>  __remove_memory+0xa/0x11
>  acpi_memory_device_remove+0x72/0x100
>  acpi_bus_trim+0x55/0x90
>  acpi_device_hotplug+0x2eb/0x3d0
>  acpi_hotplug_work_fn+0x1a/0x30
>  process_one_work+0x1a7/0x370
>  worker_thread+0x30/0x380
>  ? flush_rcu_work+0x30/0x30
>  kthread+0x112/0x130
>  ? kthread_create_on_node+0x60/0x60
>  ret_from_fork+0x35/0x40
> 
> Let's move the ->section_mem_map resetting after depopulate_section_memmap()
> to fix it.
> 
> Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug")
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Cc: stable@vger.kernel.org
> ---
>  mm/sparse.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 42c18a38ffaa..1b50c15677d7 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -734,6 +734,7 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
>  	struct mem_section *ms = __pfn_to_section(pfn);
>  	bool section_is_early = early_section(ms);
>  	struct page *memmap = NULL;
> +	bool empty = false;

Oh, one NIT: no need to initialize empty to false.


-- 
Thanks,

David / dhildenb


  parent reply	other threads:[~2020-03-09  8:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-07  8:42 [PATCH v3 0/7] mm/hotplug: Only use subsection map for VMEMMAP Baoquan He
2020-03-07  8:42 ` [PATCH v3 1/7] mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case Baoquan He
2020-03-07 20:59   ` Andrew Morton
2020-03-07 22:55     ` Baoquan He
2020-03-09  8:56   ` David Hildenbrand
2020-03-09  8:58   ` David Hildenbrand [this message]
2020-03-09 13:18     ` Baoquan He
2020-03-09 13:22       ` David Hildenbrand
2020-03-09 10:13   ` Pankaj Gupta
2020-03-09 10:13     ` Pankaj Gupta
2020-03-09 12:56   ` Michal Hocko
2020-03-07  8:42 ` [PATCH v3 2/7] mm/sparse.c: introduce new function fill_subsection_map() Baoquan He
2020-03-07  8:42 ` [PATCH v3 3/7] mm/sparse.c: introduce a new function clear_subsection_map() Baoquan He
2020-03-09  8:59   ` David Hildenbrand
2020-03-09 13:32     ` Baoquan He
2020-03-09 13:38       ` David Hildenbrand
2020-03-09 14:07         ` Baoquan He
2020-03-07  8:42 ` [PATCH v3 4/7] mm/sparse.c: only use subsection map in VMEMMAP case Baoquan He
2020-03-09  9:00   ` David Hildenbrand
2020-03-07  8:42 ` [PATCH v3 5/7] mm/sparse.c: add note about only VMEMMAP supporting sub-section support Baoquan He
2020-03-07 11:55   ` Baoquan He
2020-03-10 14:46   ` Michal Hocko
2020-03-11  4:20     ` Baoquan He
2020-03-07  8:42 ` [PATCH v3 6/7] mm/sparse.c: move subsection_map related codes together Baoquan He
2020-03-09  9:08   ` David Hildenbrand
2020-03-09 13:41     ` Baoquan He
2020-03-07  8:42 ` [PATCH v3 7/7] mm/sparse.c: Use __get_free_pages() instead in populate_section_memmap() Baoquan He
2020-03-10 14:56   ` Michal Hocko
2020-03-10 14:59     ` David Hildenbrand
2020-03-11  9:31     ` Baoquan He

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=b0ff37b3-bae1-bdd6-8a4f-62f03e028839@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=richardw.yang@linux.intel.com \
    --cc=rppt@linux.ibm.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.