From: Tejun Heo <tj@kernel.org>
To: akataria@vmware.com
Cc: linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Vandrovec <petr@vmware.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Subject: Re: (mem hotplug, pcpu_alloc) BUG: sleeping function called from invalid context at kernel/mutex.c:94
Date: Sat, 13 Nov 2010 11:09:23 +0100 [thread overview]
Message-ID: <4CDE63D3.4010608@kernel.org> (raw)
In-Reply-To: <1289588178.7486.15.camel@ank32.eng.vmware.com>
Hello,
On 11/12/2010 07:56 PM, Alok Kataria wrote:
> We have seen following might_sleep warning while hot adding memory...
>
> [ 142.339267] BUG: sleeping function called from invalid context at kernel/mutex.c:94
> [ 142.339276] in_atomic(): 0, irqs_disabled(): 1, pid: 4, name: migration/0
> [ 142.339283] Pid: 4, comm: migration/0 Not tainted 2.6.35.6-45.fc14.x86_64 #1
> [ 142.339288] Call Trace:
> [ 142.339305] [<ffffffff8103d12b>] __might_sleep+0xeb/0xf0
> [ 142.339316] [<ffffffff81468245>] mutex_lock+0x24/0x50
> [ 142.339326] [<ffffffff8110eaa6>] pcpu_alloc+0x6d/0x7ee
> [ 142.339336] [<ffffffff81048888>] ? load_balance+0xbe/0x60e
> [ 142.339343] [<ffffffff8103a1b3>] ? rt_se_boosted+0x21/0x2f
> [ 142.339349] [<ffffffff8103e1cf>] ? dequeue_rt_stack+0x18b/0x1ed
> [ 142.339356] [<ffffffff8110f237>] __alloc_percpu+0x10/0x12
> [ 142.339362] [<ffffffff81465e22>] setup_zone_pageset+0x38/0xbe
> [ 142.339373] [<ffffffff810d6d81>] ? build_zonelists_node.clone.58+0x79/0x8c
> [ 142.339384] [<ffffffff81452539>] __build_all_zonelists+0x419/0x46c
> [ 142.339395] [<ffffffff8108ef01>] ? cpu_stopper_thread+0xb2/0x198
> [ 142.339401] [<ffffffff8108f075>] stop_machine_cpu_stop+0x8e/0xc5
> [ 142.339407] [<ffffffff8108efe7>] ? stop_machine_cpu_stop+0x0/0xc5
> [ 142.339414] [<ffffffff8108ef57>] cpu_stopper_thread+0x108/0x198
> [ 142.339420] [<ffffffff81467a37>] ? schedule+0x5b2/0x5cc
> [ 142.339426] [<ffffffff8108ee4f>] ? cpu_stopper_thread+0x0/0x198
> [ 142.339434] [<ffffffff81065f29>] kthread+0x7f/0x87
> [ 142.339443] [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
> [ 142.339449] [<ffffffff81065eaa>] ? kthread+0x0/0x87
> [ 142.339455] [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
> [ 142.340099] Built 5 zonelists in Node order, mobility grouping on. Total pages: 289456
> [ 142.340108] Policy zone: Normal
>
>
> This warning was seen on the FC14 kernel, though looking at the current
> git, the problem seems to exist on mainline too.
> The problem is that pcpu_alloc expects that it is called from non-atomic
> context as a result it grabs the pcpu_alloc_mutex.
> In the memory-hotplug case though, we do end up calling pcpu_alloc from
> atomic context, while all cpus are stopped.
>
> void build_all_zonelists(void *data)
> {
> set_zonelist_order();
>
> if (system_state == SYSTEM_BOOTING) {
> __build_all_zonelists(NULL);
> mminit_verify_zonelist();
> cpuset_init_current_mems_allowed();
> } else {
> /* we have to stop all cpus to guarantee there is no user
> of zonelist */
> stop_machine(__build_all_zonelists, data, NULL); <=========
> /* cpuset refresh routine should be here */
> }
>
> __build_all_zonelists eventually calls pcpu_alloc.
>
> I didn't dive through the history, so am not sure when was this
> regression introduced, but could have regressed with the new pcpu memory
> allocator.
Meh... the percpu allocator required user context from the beginning.
The new allocator didn't change that.
Wouldn't it be possible to prepare hotplug outside of cpu_stop and use
stop_machine() only to make it available to the system. In general,
it's a very bad idea to allocate memory from inside stop_machine. The
whole machine is stopped, after all. In general, it shouldn't be too
difficult to add new resource without stop_machine too unlike removing
one. Pekka, Christoph, any ideas?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: akataria@vmware.com
Cc: linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Petr Vandrovec <petr@vmware.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Subject: Re: (mem hotplug, pcpu_alloc) BUG: sleeping function called from invalid context at kernel/mutex.c:94
Date: Sat, 13 Nov 2010 11:09:23 +0100 [thread overview]
Message-ID: <4CDE63D3.4010608@kernel.org> (raw)
In-Reply-To: <1289588178.7486.15.camel@ank32.eng.vmware.com>
Hello,
On 11/12/2010 07:56 PM, Alok Kataria wrote:
> We have seen following might_sleep warning while hot adding memory...
>
> [ 142.339267] BUG: sleeping function called from invalid context at kernel/mutex.c:94
> [ 142.339276] in_atomic(): 0, irqs_disabled(): 1, pid: 4, name: migration/0
> [ 142.339283] Pid: 4, comm: migration/0 Not tainted 2.6.35.6-45.fc14.x86_64 #1
> [ 142.339288] Call Trace:
> [ 142.339305] [<ffffffff8103d12b>] __might_sleep+0xeb/0xf0
> [ 142.339316] [<ffffffff81468245>] mutex_lock+0x24/0x50
> [ 142.339326] [<ffffffff8110eaa6>] pcpu_alloc+0x6d/0x7ee
> [ 142.339336] [<ffffffff81048888>] ? load_balance+0xbe/0x60e
> [ 142.339343] [<ffffffff8103a1b3>] ? rt_se_boosted+0x21/0x2f
> [ 142.339349] [<ffffffff8103e1cf>] ? dequeue_rt_stack+0x18b/0x1ed
> [ 142.339356] [<ffffffff8110f237>] __alloc_percpu+0x10/0x12
> [ 142.339362] [<ffffffff81465e22>] setup_zone_pageset+0x38/0xbe
> [ 142.339373] [<ffffffff810d6d81>] ? build_zonelists_node.clone.58+0x79/0x8c
> [ 142.339384] [<ffffffff81452539>] __build_all_zonelists+0x419/0x46c
> [ 142.339395] [<ffffffff8108ef01>] ? cpu_stopper_thread+0xb2/0x198
> [ 142.339401] [<ffffffff8108f075>] stop_machine_cpu_stop+0x8e/0xc5
> [ 142.339407] [<ffffffff8108efe7>] ? stop_machine_cpu_stop+0x0/0xc5
> [ 142.339414] [<ffffffff8108ef57>] cpu_stopper_thread+0x108/0x198
> [ 142.339420] [<ffffffff81467a37>] ? schedule+0x5b2/0x5cc
> [ 142.339426] [<ffffffff8108ee4f>] ? cpu_stopper_thread+0x0/0x198
> [ 142.339434] [<ffffffff81065f29>] kthread+0x7f/0x87
> [ 142.339443] [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
> [ 142.339449] [<ffffffff81065eaa>] ? kthread+0x0/0x87
> [ 142.339455] [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
> [ 142.340099] Built 5 zonelists in Node order, mobility grouping on. Total pages: 289456
> [ 142.340108] Policy zone: Normal
>
>
> This warning was seen on the FC14 kernel, though looking at the current
> git, the problem seems to exist on mainline too.
> The problem is that pcpu_alloc expects that it is called from non-atomic
> context as a result it grabs the pcpu_alloc_mutex.
> In the memory-hotplug case though, we do end up calling pcpu_alloc from
> atomic context, while all cpus are stopped.
>
> void build_all_zonelists(void *data)
> {
> set_zonelist_order();
>
> if (system_state == SYSTEM_BOOTING) {
> __build_all_zonelists(NULL);
> mminit_verify_zonelist();
> cpuset_init_current_mems_allowed();
> } else {
> /* we have to stop all cpus to guarantee there is no user
> of zonelist */
> stop_machine(__build_all_zonelists, data, NULL); <=========
> /* cpuset refresh routine should be here */
> }
>
> __build_all_zonelists eventually calls pcpu_alloc.
>
> I didn't dive through the history, so am not sure when was this
> regression introduced, but could have regressed with the new pcpu memory
> allocator.
Meh... the percpu allocator required user context from the beginning.
The new allocator didn't change that.
Wouldn't it be possible to prepare hotplug outside of cpu_stop and use
stop_machine() only to make it available to the system. In general,
it's a very bad idea to allocate memory from inside stop_machine. The
whole machine is stopped, after all. In general, it shouldn't be too
difficult to add new resource without stop_machine too unlike removing
one. Pekka, Christoph, any ideas?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-13 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 18:56 (mem hotplug, pcpu_alloc) BUG: sleeping function called from invalid context at kernel/mutex.c:94 Alok Kataria
2010-11-12 18:56 ` Alok Kataria
2010-11-13 10:09 ` Tejun Heo [this message]
2010-11-13 10:09 ` Tejun Heo
2010-11-18 7:39 ` [BUGFIX][PATCH] fix build_all_zonelist where percpu_alloc is wrongly called under stop_machine_run (Was " KAMEZAWA Hiroyuki
2010-11-18 7:39 ` 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=4CDE63D3.4010608@kernel.org \
--to=tj@kernel.org \
--cc=akataria@vmware.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
--cc=petr@vmware.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.