linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vegard Nossum <vegard.nossum@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: David Rientjes <rientjes@google.com>,
	Xishi Qiu <qiuxishi@huawei.com>, Robert Richter <rric@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	Pekka Enberg <penberg@kernel.org>, Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: mm: OS boot failed when set command-line kmemcheck=1
Date: Wed, 26 Feb 2014 11:14:41 +0100	[thread overview]
Message-ID: <CAOMGZ=F66ysRvvPKiCNDRtjDjgAZUV+KBcgjS+G0Yho5quBFPw@mail.gmail.com> (raw)
In-Reply-To: <20140226084304.GD18404@twins.programming.kicks-ass.net>

On 26 February 2014 09:43, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Feb 19, 2014 at 02:24:41PM -0800, David Rientjes wrote:
>> On Wed, 19 Feb 2014, Xishi Qiu wrote:
>>
>> > Here is a warning, I don't whether it is relative to my hardware.
>> > If set "kmemcheck=1 nowatchdog", it can boot.
>> >
>> > code:
>> >     ...
>> >     pte = kmemcheck_pte_lookup(address);
>> >     if (!pte)
>> >             return false;
>> >
>> >     WARN_ON_ONCE(in_nmi());
>> >
>> >     if (error_code & 2)
>> >     ...
>
> That code seems to assume NMI context cannot fault; this is false since
> a while back (v3.9 or thereabouts).
>
>> > [   10.920757]  [<ffffffff810452c1>] kmemcheck_fault+0xb1/0xc0
>> > [   10.920760]  [<ffffffff814d262b>] __do_page_fault+0x39b/0x4c0
>> > [   10.920763]  [<ffffffff814d2829>] do_page_fault+0x9/0x10
>> > [   10.920765]  [<ffffffff814cf222>] page_fault+0x22/0x30
>> > [   10.920774]  [<ffffffff8101eb02>] intel_pmu_handle_irq+0x142/0x3a0
>> > [   10.920777]  [<ffffffff814d0655>] perf_event_nmi_handler+0x35/0x60
>> > [   10.920779]  [<ffffffff814cfe83>] nmi_handle+0x63/0x150
>> > [   10.920782]  [<ffffffff814cffd3>] default_do_nmi+0x63/0x290
>> > [   10.920784]  [<ffffffff814d02a8>] do_nmi+0xa8/0xe0
>> > [   10.920786]  [<ffffffff814cf527>] end_repeat_nmi+0x1e/0x2e
>
> And this does indeed show a fault from NMI context; which is totally
> expected.
>
> kmemcheck needs to be fixed; but I've no clue how any of that works.

IIRC the reason we don't support page faults in NMI context is that we
may already be handling an existing fault (or trap) when the NMI hits.
So that would mess up kmemcheck's working state. I don't really see
that anything has changed in this respect lately, so it could always
have been broken.

I think the way we dealt with this before was just to make sure than
NMI handlers don't access any kmemcheck-tracked memory (i.e. to make
sure that all memory touched by NMI handlers has been marked NOTRACK).
And the purpose of this warning is just to tell us that something
inside an NMI triggered a page fault (in this specific case, it seems
to be intel_pmu_handle_irq).

I guess there are two ways forward:

 - create a stack of things that kmemcheck is working on, so that we
handle recursive page faults
 - try to figure out why intel_pmu_handle_irq() faults and add a
(kmemcheck-specific) workaround for it

Incidentally, do you remember what exactly changed wrt page faults in
NMI context?


Vegard

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-02-26 10:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19  6:56 Xishi Qiu
2014-02-19  7:49 ` David Rientjes
2014-02-19  9:35   ` Xishi Qiu
2014-02-19 22:24     ` David Rientjes
2014-02-26  8:12       ` Xishi Qiu
2014-02-26  8:43       ` Peter Zijlstra
2014-02-26 10:14         ` Vegard Nossum [this message]
2014-02-26 10:30           ` Peter Zijlstra
2014-03-12  9:15           ` Xishi Qiu
2014-02-19 22:14   ` [patch] x86, kmemcheck: Use kstrtoint() instead of sscanf() David Rientjes
2014-03-03 13:14     ` Pekka Enberg
2014-03-04  5:07       ` David Rientjes

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='CAOMGZ=F66ysRvvPKiCNDRtjDjgAZUV+KBcgjS+G0Yho5quBFPw@mail.gmail.com' \
    --to=vegard.nossum@gmail.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qiuxishi@huawei.com \
    --cc=rientjes@google.com \
    --cc=rric@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