All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zhong <zhong@linux.vnet.ibm.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	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, tony.luck@intel.com, bp@amd64.org,
	robert.richter@amd.com, lenb@kernel.org, minyard@acm.org,
	wim@iguana.be, linux-edac@vger.kernel.org,
	oprofile-list@lists.sf.net, linux-acpi@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	linux-watchdog@vger.kernel.org,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH v3 x86 1/2] fix page faults by nmiaction in nmi if kmemcheck is enabled
Date: Fri, 09 Mar 2012 04:52:36 -0500	[thread overview]
Message-ID: <1331286756.13274.26.camel@ThinkPad-T420> (raw)
In-Reply-To: <CAOMGZ=ECe+p10H4RMjcJnfa254_JGPg+BzmVuLvpZb1-Tzn4Xg@mail.gmail.com>

On Tue, 2012-03-06 at 11:27 +0100, Vegard Nossum wrote:
> On 6 March 2012 11:09, Li Zhong <zhong@linux.vnet.ibm.com> wrote:
> > This patch tries to fix the problem of page fault exception caused by
> > accessing nmiaction structure in nmi if kmemcheck is enabled.
> >
> > If kmemcheck is enabled, the memory allocated through slab are in pages
> > that are marked non-present, so that some checks could be done in the
> > page fault handling code ( e.g. whether the memory is read before
> > written to ).
> > As nmiaction is allocated in this way, so it resides in a non-present
> > page. Then there is a page fault while the nmi code accessing the
> > nmiaction structure, which would then cause a warning by
> > WARN_ON_ONCE(in_nmi()) in kmemcheck_fault(), called by do_page_fault().
> >
> > v2: as Peter suggested, changed the nmiaction to use static storage.
> >
> > v3: as Peter suggested, use macro to shorten the codes. Also keep the
> > original usage of register_nmi_handler, so users of this call doesn't
> > need change.
> >
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> 
> Looks like you've solved this now. Thanks.

There is still one place [2/2] not solved ... and I guess it might need
the way you suggested below.

> 
> For the record, another way to prevent the page fault from happening
> in the first place is to set up a new slab cache with the flag
> SLAB_NOTRACK. This is different from the GFP_NOTRACK flag which, as
> you noted, doesn't prevent page faults, just inhibits
> checking/warnings for those memory areas.
> 
> It's a bit of a hassle, I admit. Maybe we could create an additional,
> separate set of slab caches (using SLAB_NOTRACK) and a new GFP flag
> which selects this set of caches instead. This would allow anything
> that takes a gfp_t to allocate memory that is guaranteed not to page
> fault when using kmemcheck. Pekka, any thoughts?
> 

I'm not sure whether I understand it correctly? 
  If CONFIG_KMEMCHECK is enabled, create another two sets of
malloc_sizes caches, one for cs_cachep, one for cs_dmacachep, both with
SLAB_NOTRACK flag. 

  Create a new GFP flag, like __GFP_NO_PF for those places where page
fault is not allowed, and return memory from the caches created above.
This new GFP flag is set to 0 if CONFIG_KMEMCHECK is not enabled. 

I think there shouldn't be many such cases, so most of these caches
wouldn't actually be used ...

Thanks,
Zhong

> 
> Vegard
> 

  reply	other threads:[~2012-03-09  9:52 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
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 [this message]
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=1331286756.13274.26.camel@ThinkPad-T420 \
    --to=zhong@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=bp@amd64.org \
    --cc=dzickus@redhat.com \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=minyard@acm.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=oprofile-list@lists.sf.net \
    --cc=paulus@samba.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vegard.nossum@gmail.com \
    --cc=wim@iguana.be \
    --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.