Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753465AbbFCKS4 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 3 Jun 2015 06:18:56 -0400
Received: from cn.fujitsu.com ([59.151.112.132]:38770 "EHLO
	heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org
	with ESMTP id S1752157AbbFCKSs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Jun 2015 06:18:48 -0400
X-IronPort-AV: E=Sophos;i="5.01,1,1399996800"; 
   d="scan'208";a="96357375"
Message-ID: <556ECFC0.6050902@cn.fujitsu.com>
Date: Wed, 3 Jun 2015 17:58:24 +0800
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ingo Molnar <mingo@kernel.org>
CC: Andy Lutomirski <luto@amacapital.net>, "H. Peter Anvin" <hpa@zytor.com>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>
Subject: Re: [RFC PATCH V2] x86, espfix: postpone the initialization of espfix
 stack for AP
References: <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> <CALCETrVsMpduwHDDEZ7d-S6AgvUZxXnk4+Bm+fjB=gsjzpxKWA@mail.gmail.com> <556D7687.70402@cn.fujitsu.com> <20150602115915.GB20697@gmail.com>
In-Reply-To: <20150602115915.GB20697@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.167.226.100]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3283
Lines: 83

Hi Ingo,

On 06/02/2015 07:59 PM, Ingo Molnar wrote:

> 
> * Gu Zheng <guz.fnst@cn.fujitsu.com> 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]  [<ffffffff81773f0a>] dump_stack+0x4c/0x65
>> [    3.255000]  [<ffffffff8108c85a>] warn_slowpath_common+0x8a/0xc0
>> [    3.261000]  [<ffffffff8108c8e5>] warn_slowpath_fmt+0x55/0x70
>> [    3.268000]  [<ffffffff810ee24d>] lockdep_trace_alloc+0xdd/0xe0
>> [    3.274000]  [<ffffffff811cda0d>] __alloc_pages_nodemask+0xad/0xca0
>> [    3.281000]  [<ffffffff810ec7ad>] ? __lock_acquire+0xf6d/0x1560
>> [    3.288000]  [<ffffffff81219c8a>] alloc_page_interleave+0x3a/0x90
>> [    3.295000]  [<ffffffff8121b32d>] alloc_pages_current+0x17d/0x1a0
>> [    3.301000]  [<ffffffff811c869e>] ? __get_free_pages+0xe/0x50
>> [    3.308000]  [<ffffffff811c869e>] __get_free_pages+0xe/0x50
>> [    3.314000]  [<ffffffff8102640b>] init_espfix_ap+0x17b/0x320
>> [    3.320000]  [<ffffffff8105c691>] start_secondary+0xf1/0x1f0
>> [    3.327000] ---[ end trace 1b3327d9d6a1d62c ]---
>>
>> This seems a mis-warning by lockdep, 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.
> 
> Why should this be a 'mis-warning'? If the GFP_KERNEL allocation sleeps then we'll 
> sleep with irqs disabled => bad.
> 
> This looks like a real (albeit hard to trigger) bug.


You are right.
Thanks for correct me, I misread the log.

> 
>> 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 after cpu booted to avoid the noise.
> 
>> -void init_espfix_ap(void)
>> +void init_espfix_ap(int cpu)
>>  {
> 
> So how about the concern I raised in a former thread, that the allocation should 
> be done for the node the target CPU is on? The 'cpu' parameter should be 
> propagated to the allocation as well, and turned into a node allocation or so.
> 
> Even though some CPUs will share the espfix stack, some won't.


Hmm, sounds reasonable.

Regards,
Gu

> 
> 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/