Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752858AbbF2GtN (ORCPT ); Mon, 29 Jun 2015 02:49:13 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:34227 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398AbbF2GtD (ORCPT ); Mon, 29 Jun 2015 02:49:03 -0400 Date: Mon, 29 Jun 2015 08:48:59 +0200 From: Ingo Molnar To: Borislav Petkov Cc: Zhu Guihua , hpa@zytor.com, linux-kernel@vger.kernel.org, luto@amacapital.net, luto@kernel.org, tglx@linutronix.de, x86@kernel.org Subject: Re: [PATCH v2] x86, espfix: init espfix on the boot cpu side Message-ID: <20150629064858.GA17256@gmail.com> References: <1435311202-13248-1-git-send-email-zhugh.fnst@cn.fujitsu.com> <20150627085536.GB26543@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150627085536.GB26543@pd.tnic> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3134 Lines: 68 * Borislav Petkov wrote: > On Fri, Jun 26, 2015 at 05:33:22PM +0800, Zhu Guihua 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. > > > > So we allocate them on the boot CPU side when the target CPU is bringing > > up by the primary CPU, and hand them over to the secondary CPU. > > > > Signed-off-by: Zhu Guihua > > --- > > v2: > > -allocate espfix stack pages when the targert CPU is bringing up by the > > primary CPU > > -commit messages changed > > v1: > > -Alloc the page on the node the target CPU is on. > > RFC v2: > > -Let the boot up routine init the espfix stack for the target cpu after it > > booted. > > Looks ok to me and it works on the 16-node NUMA guest I was triggering the splat > with. > > hpa, is that what you had in mind? Looks good to me, but please split it into two parts: one that pushes down the CPU index - another that does the actual change. Should this break anything then being in two parts will make it much easier to bisect to. Thanks, Ingo -- 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/