From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, paulus@samba.org, mingo@elte.hu,
acme@ghostprotocols.net
Subject: Re: [PATCH 0/2 x86] fix some page faults in nmi if kmemcheck is enabled
Date: Tue, 21 Feb 2012 11:17:17 +0100 [thread overview]
Message-ID: <1329819437.2293.382.camel@twins> (raw)
In-Reply-To: <1329788560.3448.45.camel@ThinkPad-T61>
On Tue, 2012-02-21 at 09:42 +0800, Li Zhong wrote:
> > Hell no, these are some of the ugliest patches I've seen in a while. Not
> > to mention that their changelogs are utter crap since they don't even
> > explain why they're doing what they're doing.
> >
> Hi Peter,
>
> I agree that the fix is ugly. I'm willing to change if there are some
> better ways.
There are always better ways..
> The problem here is:
> 1. It seems x86 doesn't allow page faults in nmi, and there are checks
> in the code, like WARN_ON_ONCE(in_nmi()).
I bet that's not x86 only..
> 2. If CONFIG_KMEMCHECK is enabled, the pages allocated through slab will
> be marked as non-present, to capture uninitialized memory access. More
> information in Documentation/kmemcheck.txt .
So then kmemcheck is buggy, since the nmiaction structure is initialized
in register_nmi_handler(), so it should most definitely not be marked
non-present.
> 3. From the log, there are some memories accessed in nmi, which are in
> pages marked as non-present by kmemcheck, as they are allocated by
> something like kmalloc().
So figure out why and fix that instead of writing ugly ass patches that
seemingly work around the problem without actually thinking about it.
next prev parent reply other threads:[~2012-02-21 10:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 6:01 [PATCH 0/2 x86] fix some page faults in nmi if kmemcheck is enabled Li Zhong
2012-02-20 6:04 ` [PATCH 1/2 x86] fix page faults by nmi handler " Li Zhong
2012-02-20 6:07 ` [PATCH 2/2 x86] fix page faults by perf events " Li Zhong
2012-02-20 11:00 ` [PATCH 0/2 x86] fix some page faults " Peter Zijlstra
2012-02-21 1:42 ` Li Zhong
2012-02-21 10:17 ` Peter Zijlstra [this message]
2012-02-23 9:53 ` Li Zhong
2012-02-27 10:58 ` Peter Zijlstra
2012-02-28 2:45 ` Li Zhong
2012-03-02 19:44 ` Don Zickus
2012-03-05 1:49 ` Li Zhong
2012-03-05 10:05 ` [PATCH v2 x86 1/2] fix page faults by nmiaction " Li Zhong
2012-03-05 10:29 ` Wim Van Sebroeck
2012-03-06 1:46 ` Li Zhong
2012-03-05 15:54 ` Don Zickus
2012-03-05 17:55 ` Peter Zijlstra
2012-03-05 17:49 ` Peter Zijlstra
2012-03-05 21:45 ` Don Zickus
2012-03-06 10:09 ` [PATCH v3 " Li Zhong
2012-03-06 10:27 ` Vegard Nossum
2012-03-09 9:52 ` Li Zhong
2012-03-06 15:00 ` Don Zickus
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=1329819437.2293.382.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=zhong@linux.vnet.ibm.com \
/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