Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757887AbbFQH1n (ORCPT ); Wed, 17 Jun 2015 03:27:43 -0400 Received: from terminus.zytor.com ([198.137.202.10]:40636 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757542AbbFQH1e (ORCPT ); Wed, 17 Jun 2015 03:27:34 -0400 Message-ID: <55812149.1040804@zytor.com> Date: Wed, 17 Jun 2015 00:27:05 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gu Zheng , Ingo Molnar CC: Andy Lutomirski , Andy Lutomirski , Borislav Petkov , Thomas Gleixner , "linux-kernel@vger.kernel.org" , X86 ML Subject: Re: [PATCH V1] x86, espfix: postpone the initialization of espfix stack for AP References: <1431603465-12610-1-git-send-email-guz.fnst@cn.fujitsu.com> <20150514122621.GB29235@pd.tnic> <20150514182954.GB23479@gmail.com> <20150514212753.GE29125@pd.tnic> <55551E07.8080509@zytor.com> <20150515065417.GB29973@gmail.com> <55559FDA.3010205@zytor.com> <555A40C9.6010605@kernel.org> <555B5105.4040808@zytor.com> <555F0139.9040404@cn.fujitsu.com> <55666D4A.5040006@cn.fujitsu.com> <556D7687.70402@cn.fujitsu.com> <55701E54.6090802@cn.fujitsu.com> In-Reply-To: <55701E54.6090802@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2864 Lines: 53 On 06/04/2015 02:45 AM, Gu Zheng wrote: > The following lockdep warning occurrs when running with latest kernel: > [ 3.178000] ------------[ cut here ]------------ > [ 3.183000] WARNING: CPU: 128 PID: 0 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0xdd/0xe0() > [ 3.193000] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [ 3.199000] Modules linked in: > > [ 3.203000] CPU: 128 PID: 0 Comm: swapper/128 Not tainted 4.1.0-rc3 #70 > [ 3.221000] 0000000000000000 2d6601fb3e6d4e4c ffff88086fd5fc38 ffffffff81773f0a > [ 3.230000] 0000000000000000 ffff88086fd5fc90 ffff88086fd5fc78 ffffffff8108c85a > [ 3.238000] ffff88086fd60000 0000000000000092 ffff88086fd60000 00000000000000d0 > [ 3.246000] Call Trace: > [ 3.249000] [] dump_stack+0x4c/0x65 > [ 3.255000] [] warn_slowpath_common+0x8a/0xc0 > [ 3.261000] [] warn_slowpath_fmt+0x55/0x70 > [ 3.268000] [] lockdep_trace_alloc+0xdd/0xe0 > [ 3.274000] [] __alloc_pages_nodemask+0xad/0xca0 > [ 3.281000] [] ? __lock_acquire+0xf6d/0x1560 > [ 3.288000] [] alloc_page_interleave+0x3a/0x90 > [ 3.295000] [] alloc_pages_current+0x17d/0x1a0 > [ 3.301000] [] ? __get_free_pages+0xe/0x50 > [ 3.308000] [] __get_free_pages+0xe/0x50 > [ 3.314000] [] init_espfix_ap+0x17b/0x320 > [ 3.320000] [] start_secondary+0xf1/0x1f0 > [ 3.327000] ---[ end trace 1b3327d9d6a1d62c ]--- > > As we alloc pages with GFP_KERNEL in init_espfix_ap() which is called > before enabled local irq, and the lockdep sub-system considers this > behaviour as allocating memory with GFP_FS with local irq disabled, > then trigger the warning as mentioned about. > > Though we could allocate them on the boot CPU side and hand them over to > the secondary CPU, but it seemes a bit waste if some of cpus are offline. > As thers is no need to these pages(espfix stack) until we try to run user > code, so we postpone the initialization of espfix stack, and let the boot > up routine init the espfix stack for the target cpu after it booted to > avoid the noise. > It isn't *at all* obvious to me at least that if the GFP_KERNEL allocation fails we may not get rescheduled on another CPU and/or get stuck. I'm starting to think that the right thing to do is to allocate these on the CPU that is bringing up the other CPU, at the same time we allocate the percpu area. This won't affect offline CPUs. -hpa -- 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/