public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Quentin Barnes <qbarnes@urbana.css.mot.com>
Cc: Andi Kleen <andi@firstfloor.org>, systemtap@sources.redhat.com
Subject: Re: notify_page_fault() problem
Date: Tue, 01 May 2007 02:57:00 -0000	[thread overview]
Message-ID: <20070501025659.GA16649@one.firstfloor.org> (raw)
In-Reply-To: <20070430211537.GA7723@urbana.css.mot.com>

> However, vmalloc_sync_all() is i386 and x86_64 specific as well
> as their change to register_page_fault_notifier().  I don't see
> other platform doing anything else doing anything special in their
> register_page_fault_notifier().  

They probably just haven't tested this particular case yet.
x86 also did it originally to handle NMI notifiers, which is a x86 special
(nested pagefault in NMI can lead to stack corruption because
NMIs are only blocked until the next IRET)

> I have trouble believing that x86
> and ARM are unique somehow with needing to address this problem.
> Why doesn't anyone else hit this?  Is it a lurking problem or are
> there other fixes in other forms out there?

The standard kprobes notifier is not modular so it won't hit this.
 
> I guess part of the answer has to do with what people's expectations
> are for intercepting faults with their kprobes fault handler though.

Yes, some have pretty broad exceptions.  It might be possible
to move it to a kernel address only path, but then some debuggers
seem to want to debug user mode too.

But you're right there has been grumbling about the overhead
of the notifier call in the hot path.

-Andi

  reply	other threads:[~2007-05-01  2:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30 20:19 Quentin Barnes
2007-04-30 20:25 ` Andi Kleen
2007-04-30 21:15   ` Quentin Barnes
2007-05-01  2:57     ` Andi Kleen [this message]
2007-05-01  3:24       ` Quentin Barnes
2007-05-01 15:40         ` Frank Ch. Eigler
2007-05-01 15:43           ` Quentin Barnes
2007-05-02 10:33           ` Andi Kleen

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=20070501025659.GA16649@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=qbarnes@urbana.css.mot.com \
    --cc=systemtap@sources.redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).