public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Baoquan He <bhe@redhat.com>
Cc: Dave Young <dyoung@redhat.com>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, <tglx@linutronix.de>,
	<akpm@linux-foundation.org>, <isimatu.yasuaki@jp.fujitsu.com>,
	<mingo@redhat.com>, <hpa@zytor.com>
Subject: Re: [PATCH V2] x86/numa: kernel stack corruption fix
Date: Wed, 8 Apr 2015 10:41:54 +0800	[thread overview]
Message-ID: <55249572.7010600@huawei.com> (raw)
In-Reply-To: <20150408021836.GA2464@dhcp-16-105.nay.redhat.com>

On 2015/4/8 10:18, Baoquan He wrote:

> On 04/08/15 at 09:59am, Xishi Qiu wrote:
>> On 2015/4/8 9:46, Dave Young wrote:
>>
>>>>>  
>>>>> -	/* Mark all kernel nodes. */
>>>>> +	/*
>>>>> +	 * Mark all kernel nodes.
>>>>> +	 *
>>>>> +	 * In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo
>>>>
>>>> Hi Dave,
>>>>
>>>> It should both set mem=xx and numa=off, then numa_meminfo may not include all
>>>> the memblock.reserved memory, right?
>>>
>>> Yasuaki Ishimatsu suggests to remove numa=off in comment because in theory there's such
>>> possiblity that it may happen even without numa=off. Just consider the non-snb board..
>>>
>>> Thanks
>>> Dave
>>>
>>
>> Hi Dave,
>>
>> I made a mistake, when numa is on, numa_meminfo is from SRAT, but it will be cut
>> in numa_cleanup_meminfo(), so the bug is not related to numa on/off. Your comment
>> is right.
> 
> Hi Xishi,
> 
>>From code flow it's exact as you said. And if remove numa=off bug should
> be reproduced alwasy. I talked to Dave, he said error didn't occur when
> he remove numa=off. That is too weird.
> 

Hi Baoquan,

May be it wrote over end of numa mask bitmap, but the stack can still run,
so there is no Call Trace. 
How about add some printk to see if it has written over? 

Thanks,
Xishi Qiu

> Thanks
> Baoquan > 
>>
>>> .
>>>
>>
>>
>>
> 
> .
> 




  reply	other threads:[~2015-04-08  2:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-07 13:41 [PATCH V2] x86/numa: kernel stack corruption fix Dave Young
2015-04-07 14:09 ` [tip:x86/urgent] x86/mm/numa: Fix kernel stack corruption in numa_init()-> numa_clear_kernel_node_hotplug() tip-bot for Dave Young
2015-04-08  1:36 ` [PATCH V2] x86/numa: kernel stack corruption fix Xishi Qiu
2015-04-08  1:46   ` Dave Young
2015-04-08  1:59     ` Xishi Qiu
2015-04-08  2:18       ` Baoquan He
2015-04-08  2:41         ` Xishi Qiu [this message]
2015-04-08  3:09           ` Dave Young
2015-04-09  3:27             ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55249572.7010600@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox