Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932734Ab2E0BHh (ORCPT ); Sat, 26 May 2012 21:07:37 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:54259 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932400Ab2E0BHU (ORCPT ); Sat, 26 May 2012 21:07:20 -0400 Message-Id: <20120527010425.900739036@linuxfoundation.org> User-Agent: quilt/0.60-19.1 Date: Sun, 27 May 2012 10:04:38 +0900 From: Greg KH To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Steven Rostedt , David Rientjes Subject: [ 15/94] Fix blocking allocations called very early during bootup In-Reply-To: <20120527010332.GA11170@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2606 Lines: 72 3.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream. During early boot, when the scheduler hasn't really been fully set up, we really can't do blocking allocations because with certain (dubious) configurations the "might_resched()" calls can actually result in scheduling events. We could just make such users always use GFP_ATOMIC, but quite often the code that does the allocation isn't really aware of the fact that the scheduler isn't up yet, and forcing that kind of random knowledge on the initialization code is just annoying and not good for anybody. And we actually have a the 'gfp_allowed_mask' exactly for this reason: it's just that the kernel init sequence happens to set it to allow blocking allocations much too early. So move the 'gfp_allowed_mask' initialization from 'start_kernel()' (which is some of the earliest init code, and runs with preemption disabled for good reasons) into 'kernel_init()'. kernel_init() is run in the newly created thread that will become the 'init' process, as opposed to the early startup code that runs within the context of what will be the first idle thread. So by the time we reach 'kernel_init()', we know that the scheduler must be at least limping along, because we've already scheduled from the idle thread into the init thread. Reported-by: Steven Rostedt Cc: David Rientjes Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- init/main.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/init/main.c +++ b/init/main.c @@ -558,9 +558,6 @@ asmlinkage void __init start_kernel(void early_boot_irqs_disabled = false; local_irq_enable(); - /* Interrupts are enabled now so all GFP allocations are safe. */ - gfp_allowed_mask = __GFP_BITS_MASK; - kmem_cache_init_late(); /* @@ -792,6 +789,10 @@ static int __init kernel_init(void * unu * Wait until kthreadd is all set-up. */ wait_for_completion(&kthreadd_done); + + /* Now the scheduler is fully set up and can do blocking allocations */ + gfp_allowed_mask = __GFP_BITS_MASK; + /* * init can allocate pages on any node */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/