From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id 6F72C8D0001 for ; Sat, 13 Nov 2010 05:09:54 -0500 (EST) Message-ID: <4CDE63D3.4010608@kernel.org> Date: Sat, 13 Nov 2010 11:09:23 +0100 From: Tejun Heo MIME-Version: 1.0 Subject: Re: (mem hotplug, pcpu_alloc) BUG: sleeping function called from invalid context at kernel/mutex.c:94 References: <1289588178.7486.15.camel@ank32.eng.vmware.com> In-Reply-To: <1289588178.7486.15.camel@ank32.eng.vmware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: akataria@vmware.com Cc: linux-mm , LKML , Andrew Morton , Petr Vandrovec , Pekka Enberg , Christoph Lameter List-ID: 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] [] __might_sleep+0xeb/0xf0 > [ 142.339316] [] mutex_lock+0x24/0x50 > [ 142.339326] [] pcpu_alloc+0x6d/0x7ee > [ 142.339336] [] ? load_balance+0xbe/0x60e > [ 142.339343] [] ? rt_se_boosted+0x21/0x2f > [ 142.339349] [] ? dequeue_rt_stack+0x18b/0x1ed > [ 142.339356] [] __alloc_percpu+0x10/0x12 > [ 142.339362] [] setup_zone_pageset+0x38/0xbe > [ 142.339373] [] ? build_zonelists_node.clone.58+0x79/0x8c > [ 142.339384] [] __build_all_zonelists+0x419/0x46c > [ 142.339395] [] ? cpu_stopper_thread+0xb2/0x198 > [ 142.339401] [] stop_machine_cpu_stop+0x8e/0xc5 > [ 142.339407] [] ? stop_machine_cpu_stop+0x0/0xc5 > [ 142.339414] [] cpu_stopper_thread+0x108/0x198 > [ 142.339420] [] ? schedule+0x5b2/0x5cc > [ 142.339426] [] ? cpu_stopper_thread+0x0/0x198 > [ 142.339434] [] kthread+0x7f/0x87 > [ 142.339443] [] kernel_thread_helper+0x4/0x10 > [ 142.339449] [] ? kthread+0x0/0x87 > [ 142.339455] [] ? 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: email@kvack.org