linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,
	sparclinux@vger.kernel.org, cl@linux.com,
	linux-s390@vger.kernel.org, x86@kernel.org,
	linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
	linfeng@cn.fujitsu.com, mgorman@suse.de,
	kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, wency@cn.fujitsu.com,
	cmetcalf@tilera.com, wujianguo@huawei.com, yinghai@kernel.org,
	laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	minchan.kim@gmail.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 07/14] memory-hotplug: move pgdat_resize_lock into sparse_remove_one_section()
Date: Wed, 26 Dec 2012 14:20:41 +0800	[thread overview]
Message-ID: <50DA9739.3070907@cn.fujitsu.com> (raw)
In-Reply-To: <50DA7357.109@jp.fujitsu.com>

On 12/26/2012 11:47 AM, Kamezawa Hiroyuki wrote:
> (2012/12/24 21:09), Tang Chen wrote:
>> In __remove_section(), we locked pgdat_resize_lock when calling
>> sparse_remove_one_section(). This lock will disable irq. But we don't need
>> to lock the whole function. If we do some work to free pagetables in
>> free_section_usemap(), we need to call flush_tlb_all(), which need
>> irq enabled. Otherwise the WARN_ON_ONCE() in smp_call_function_many()
>> will be triggered.
>>
>> Signed-off-by: Tang Chen<tangchen@cn.fujitsu.com>
>> Signed-off-by: Lai Jiangshan<laijs@cn.fujitsu.com>
>> Signed-off-by: Wen Congyang<wency@cn.fujitsu.com>
> 
> If this is a bug fix, call-trace in your log and BUGFIX or -fix- in patch title
> will be appreciated, I think.
> 
> Acked-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> 
Hi Kamezawa-san,

Thanks for the reviewing.

I don't think this would be a bug. It is OK to lock the whole
sparse_remove_one_section() if no tlb flushing in free_section_usemap().

But we need to flush tlb in free_section_usemap(), so we need to take
free_section_usemap() out of the lock. :)

I add the call trace to the patch so that people could review it more
easily.

And here is the call trace for this version:

[  454.796248] ------------[ cut here ]------------
[  454.851408] WARNING: at kernel/smp.c:461
smp_call_function_many+0xbd/0x260()
[  454.935620] Hardware name: PRIMEQUEST 1800E
......
[  455.652201] Call Trace:
[  455.681391]  [<ffffffff8106e73f>] warn_slowpath_common+0x7f/0xc0
[  455.753151]  [<ffffffff810560a0>] ? leave_mm+0x50/0x50
[  455.814527]  [<ffffffff8106e79a>] warn_slowpath_null+0x1a/0x20
[  455.884208]  [<ffffffff810e7a9d>] smp_call_function_many+0xbd/0x260
[  455.959082]  [<ffffffff810e7ecb>] smp_call_function+0x3b/0x50
[  456.027722]  [<ffffffff810560a0>] ? leave_mm+0x50/0x50
[  456.089098]  [<ffffffff810e7f4b>] on_each_cpu+0x3b/0xc0
[  456.151512]  [<ffffffff81055f0c>] flush_tlb_all+0x1c/0x20
[  456.216004]  [<ffffffff8104f8de>] remove_pagetable+0x14e/0x1d0
[  456.285683]  [<ffffffff8104f978>] vmemmap_free+0x18/0x20
[  456.349139]  [<ffffffff811b8797>] sparse_remove_one_section+0xf7/0x100
[  456.427126]  [<ffffffff811c5fc2>] __remove_section+0xa2/0xb0
[  456.494726]  [<ffffffff811c6070>] __remove_pages+0xa0/0xd0
[  456.560258]  [<ffffffff81669c7b>] arch_remove_memory+0x6b/0xc0
[  456.629937]  [<ffffffff8166ad28>] remove_memory+0xb8/0xf0
[  456.694431]  [<ffffffff813e686f>] acpi_memory_device_remove+0x53/0x96
[  456.771379]  [<ffffffff813b33c4>] acpi_device_remove+0x90/0xb2
[  456.841059]  [<ffffffff8144b02c>] __device_release_driver+0x7c/0xf0
[  456.915928]  [<ffffffff8144b1af>] device_release_driver+0x2f/0x50
[  456.988719]  [<ffffffff813b4476>] acpi_bus_remove+0x32/0x6d
[  457.055285]  [<ffffffff813b4542>] acpi_bus_trim+0x91/0x102
[  457.120814]  [<ffffffff813b463b>] acpi_bus_hot_remove_device+0x88/0x16b
[  457.199840]  [<ffffffff813afda7>] acpi_os_execute_deferred+0x27/0x34
[  457.275756]  [<ffffffff81091ece>] process_one_work+0x20e/0x5c0
[  457.345434]  [<ffffffff81091e5f>] ? process_one_work+0x19f/0x5c0
[  457.417190]  [<ffffffff813afd80>] ?
acpi_os_wait_events_complete+0x23/0x23
[  457.499332]  [<ffffffff81093f6e>] worker_thread+0x12e/0x370
[  457.565896]  [<ffffffff81093e40>] ? manage_workers+0x180/0x180
[  457.635574]  [<ffffffff8109a09e>] kthread+0xee/0x100
[  457.694871]  [<ffffffff810dfaf9>] ? __lock_release+0x129/0x190
[  457.764552]  [<ffffffff81099fb0>] ? __init_kthread_worker+0x70/0x70
[  457.839427]  [<ffffffff81690aac>] ret_from_fork+0x7c/0xb0
[  457.903914]  [<ffffffff81099fb0>] ? __init_kthread_worker+0x70/0x70
[  457.978784] ---[ end trace 25e85300f542aa01 ]---

Thanks. :)

  reply	other threads:[~2012-12-26  6:21 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-24 12:09 [PATCH v5 00/14] memory-hotplug: hot-remove physical memory Tang Chen
2012-12-24 12:09 ` [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence Tang Chen
2012-12-25  8:35   ` Glauber Costa
2012-12-30  5:58     ` Wen Congyang
2013-01-09 15:09       ` Glauber Costa
2013-01-10  1:38         ` Tang Chen
2013-02-06  3:07         ` Tang Chen
2013-02-06  9:17           ` Tang Chen
2013-02-06 10:10             ` Tang Chen
2013-02-06 14:24               ` Glauber Costa
2013-02-07  7:56                 ` Tang Chen
2012-12-26  3:02   ` Kamezawa Hiroyuki
2012-12-30  5:49     ` Wen Congyang
2012-12-24 12:09 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Tang Chen
2012-12-26  3:10   ` Kamezawa Hiroyuki
2012-12-27  3:10     ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 03/14] memory-hotplug: remove redundant codes Tang Chen
2012-12-26  3:20   ` Kamezawa Hiroyuki
2012-12-27  3:09     ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 04/14] memory-hotplug: remove /sys/firmware/memmap/X sysfs Tang Chen
2012-12-26  3:30   ` Kamezawa Hiroyuki
2012-12-27  3:09     ` Tang Chen
2013-01-02 14:24       ` Christoph Lameter
2012-12-24 12:09 ` [PATCH v5 05/14] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Tang Chen
2012-12-26  3:37   ` Kamezawa Hiroyuki
2012-12-24 12:09 ` [PATCH v5 06/14] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap Tang Chen
2012-12-25  8:09   ` Jianguo Wu
2012-12-26  3:21     ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 07/14] memory-hotplug: move pgdat_resize_lock into sparse_remove_one_section() Tang Chen
2012-12-26  3:47   ` Kamezawa Hiroyuki
2012-12-26  6:20     ` Tang Chen [this message]
2012-12-24 12:09 ` [PATCH v5 08/14] memory-hotplug: Common APIs to support page tables hot-remove Tang Chen
2012-12-25  8:17   ` Jianguo Wu
2012-12-26  2:49     ` Tang Chen
2012-12-26  3:11       ` Tang Chen
2012-12-26  3:19         ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 09/14] memory-hotplug: remove page table of x86_64 architecture Tang Chen
2012-12-24 12:09 ` [PATCH v5 10/14] memory-hotplug: remove memmap of sparse-vmemmap Tang Chen
2012-12-24 12:09 ` [PATCH v5 11/14] memory-hotplug: Integrated __remove_section() of CONFIG_SPARSEMEM_VMEMMAP Tang Chen
2012-12-24 12:09 ` [PATCH v5 12/14] memory-hotplug: memory_hotplug: clear zone when removing the memory Tang Chen
2012-12-24 12:09 ` [PATCH v5 13/14] memory-hotplug: remove sysfs file of node Tang Chen
2012-12-24 12:09 ` [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined Tang Chen
2012-12-26  3:55   ` Kamezawa Hiroyuki
2012-12-27 12:16     ` Wen Congyang
2012-12-28  0:28       ` Kamezawa Hiroyuki
2012-12-30  6:02         ` Wen Congyang
2013-01-07  5:30           ` Kamezawa Hiroyuki

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=50DA9739.3070907@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=cmetcalf@tilera.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linfeng@cn.fujitsu.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=liuj97@gmail.com \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=wency@cn.fujitsu.com \
    --cc=wujianguo@huawei.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).