From: Pekka Paalanen <pq@iki.fi>
To: linux-kernel@vger.kernel.org
Cc: jbeulich@novell.com, proski@gnu.org
Subject: Replacement for page fault notifiers?
Date: Tue, 8 Jan 2008 21:06:38 +0200 [thread overview]
Message-ID: <20080108210638.5c9e093a@daedalus.pq.iki.fi> (raw)
Hello,
the commit "x86: optimize page faults like all other achitectures and
kill notifier cruft" by Christoph Hellwig removed the page fault
notifiers (e.g. register_page_fault_notifier()) completely in 2.6.24.
Mmio-trace [1] is using them for tracking memory mapped IO, and also
other people have mentioned they need it [2,3].
This is roughly how I understand mmio-trace is working. In a loadable
kernel module calls to __ioremap() are diverted to an mmio-trace
specific function. The function calls the real __ioremap() and marks
the returned pages as not present. Access to the mapped IO memory
causes a page fault. Mmio-trace's page fault handler marks the page
present, records the event, single-steps the faulting instruction, and
finally marks the page as not present again.
- Is there anything coming to replace register_page_fault_notifier()?
- Has someone found another way to accomplish the same without patching
the kernel?
- Should I start writing a patch to bring back the notifiers, based on
the commit that removed them?
People started to complain to me that mmio-trace does not compile for
2.6.24. At least the Nouveau project is a regular user of mmio-trace
for reverse-engineering, and the tool should be easy to use. Therefore
I would prefer not to force casual contributors to patch their kernels
as it might be too much for some. I am hoping that 2.6.25, if not
2.6.24, would contain a mechanism to accomplish what I need.
I am not a subscriber, so please keep me in CC. Also I CC'd the people
who wrote about the same issue in the past.
Thanks.
[1] http://nouveau.freedesktop.org/wiki/MmioTrace
[2] http://marc.info/?l=linux-kernel&m=119540769014745&w=2
[3] http://article.gmane.org/gmane.linux.kernel/609521
--
Pekka Paalanen
http://www.iki.fi/pq/
next reply other threads:[~2008-01-08 19:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 19:06 Pekka Paalanen [this message]
2008-01-08 20:32 ` Christoph Hellwig
2008-01-08 22:13 ` Dave Airlie
2008-01-09 0:26 ` Benjamin Herrenschmidt
2008-01-09 18:18 ` Pavel Roskin
2008-01-09 18:21 ` Christoph Hellwig
2008-01-09 19:58 ` Benjamin Herrenschmidt
2008-01-09 20:22 ` Christoph Hellwig
2008-01-10 0:42 ` Arjan van de Ven
2008-01-10 0:47 ` Andi Kleen
2008-01-10 0:55 ` Arjan van de Ven
2008-01-10 0:58 ` Benjamin Herrenschmidt
2008-01-10 1:01 ` Andi Kleen
2008-01-10 0:56 ` Benjamin Herrenschmidt
2008-01-10 2:03 ` Matt Mackall
2008-01-10 2:21 ` Pavel Roskin
2008-01-10 2:30 ` Matt Mackall
2008-01-10 18:44 ` Pekka Paalanen
2008-01-09 20:24 ` Pavel Roskin
2008-01-09 20:26 ` Christoph Hellwig
2008-01-09 20:41 ` Pavel Roskin
2008-01-09 20:44 ` Valdis.Kletnieks
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=20080108210638.5c9e093a@daedalus.pq.iki.fi \
--to=pq@iki.fi \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=proski@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®