From: Li Zhong <zhong@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
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: Thu, 23 Feb 2012 17:53:48 +0800 [thread overview]
Message-ID: <1329990828.19165.36.camel@ThinkPad-T61> (raw)
In-Reply-To: <1329819437.2293.382.camel@twins>
On Tue, 2012-02-21 at 11:17 +0100, Peter Zijlstra wrote:
> 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..
Hi Peter,
I will think further about it, and would appreciate it if you could give
some good ideas.
>
> > 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..
Maybe, I found this problem on x86, didn't check other archs.
However, from Documentation/kmemcheck.txt, seems kmemcheck only supports
x86.
>
> > 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?
But for kmemcheck, why need it know the information that page fault is
not allowed in nmi?
Or maybe I misunderstand your point here?
> > 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.
Thanks,
Zhong
next prev parent reply other threads:[~2012-02-23 10:08 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 [this message]
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=1329990828.19165.36.camel@ThinkPad-T61 \
--to=zhong@linux.vnet.ibm.com \
--cc=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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.