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, Vegard Nossum <vegardno@ifi.uio.no>,
Don Zickus <dzickus@redhat.com>
Subject: Re: [PATCH 0/2 x86] fix some page faults in nmi if kmemcheck is enabled
Date: Mon, 27 Feb 2012 11:58:44 +0100 [thread overview]
Message-ID: <1330340324.11248.60.camel@twins> (raw)
In-Reply-To: <1329990828.19165.36.camel@ThinkPad-T61>
On Thu, 2012-02-23 at 17:53 +0800, Li Zhong wrote:
> I will think further about it, and would appreciate it if you could give
> some good ideas.
*sigh*.. or you could do your own damn work..
> > > 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.
> >
>
> I'm not sure whether I understand it correctly. Do you mean that
> nmiaction is initialized in register_nmi_handler(), which indicates it
> will be used in nmi, so it shouldn't be marked non-present?
No, you said that it marks memory non-present to detect uninitialized
stuff, but since it is initialized, it shouldn't then be non-present,
right?
> But for kmemcheck, why need it know the information that page fault is
> not allowed in nmi?
Uh, what?
> > > 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.
> >
>
> I think the reason is that kmalloc ( or kzalloc ... ) uses malloc_sizes
> slab caches to allocate memory. The malloc_sizes slab caches is set up
> without SLAB_NOTRACK flag, then kmemcheck marks the pages non-present to
> do its check in page fault handling code. I think we shouldn't disable
> kmemechek for the general malloc_sizes caches.
Nobody said you should.. there's plenty of solutions that aren't ass
backward stupid nor as ugly.
First you need to figure out why the page is marked non-present since
the data structure is initialized (I've got a fair idea why), then look
if you can tell kmemcheck not to be silly like that.
Alternatively you can change the nmi stuff to use static storage like
other notifiers (see notifier_block).
What you don't ever do is write alternative code paths that are never
ever used except for debugging, that is just asking for problems.
next prev parent reply other threads:[~2012-02-27 10:59 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
2012-02-23 9:53 ` Li Zhong
2012-02-27 10:58 ` Peter Zijlstra [this message]
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=1330340324.11248.60.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=dzickus@redhat.com \
--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=vegardno@ifi.uio.no \
--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;
as well as URLs for NNTP newsgroup(s).