Need help with register_page_fault_notifier() replacement in 2.6.24

Need help with register_page_fault_notifier() replacement in 2.6.24

[Pavel Roskin]

Hello!

I'm trying to update a special tracing version of madwifi (driver for
Atheros wireless cards) for Linux 2.6.24.  This version was created to
help reverse engineering the non-free part of the driver (also known as
HAL, hardware abstraction layer).

The problem is that functions register_page_fault_notifier() and
unregister_page_fault_notifier() are gone in the current kernel git
repository.

They are needed to intercept access to the card by causing page fault
and intercepting it.

Those functions were removed on i386 platform because kprobes now
registers the flat handler directly.  The log says that other callers
are supposed to use kprobes now.

But what would be the right way to do it?  I can intercept
do_page_fault() with kprobes, but that looks unsafe, since
do_page_fault() is used by kprobes internally.

Or maybe I should install a fault handler with register_kprobe()?  The
problem is, it is only called for faults in kp->pre_handler and
kp->post_handler and for single-stepping.  I don't want to single-step
anything, and moving all driver functionality in kp->pre_handler would
be strange.

Perhaps I'm missing something obvious.  Any help will be appreciated.

-- 
Regards,
Pavel Roskin

Re: Need help with register_page_fault_notifier() replacement in 2.6.24

[Arjan van de Ven]

On Sun, 18 Nov 2007 12:40:16 -0500
Pavel Roskin <proski@gnu.org> wrote:

> Hello!
> 
> I'm trying to update a special tracing version of madwifi (driver for
> Atheros wireless cards) for Linux 2.6.24.  This version was created to
> help reverse engineering the non-free part of the driver (also known
> as HAL, hardware abstraction layer).
> 
> The problem is that functions register_page_fault_notifier() and
> unregister_page_fault_notifier() are gone in the current kernel git
> repository.
> 
> They are needed to intercept access to the card by causing page fault
> and intercepting it.
> 
> Those functions were removed on i386 platform because kprobes now
> registers the flat handler directly.  The log says that other callers
> are supposed to use kprobes now.
> 
> But what would be the right way to do it?  I can intercept
> do_page_fault() with kprobes, but that looks unsafe, since
> do_page_fault() is used by kprobes internally.
> 
> Or maybe I should install a fault handler with register_kprobe()?  The
> problem is, it is only called for faults in kp->pre_handler and
> kp->post_handler and for single-stepping.  I don't want to single-step
> anything, and moving all driver functionality in kp->pre_handler would
> be strange.
> 
> Perhaps I'm missing something obvious.  Any help will be appreciated.
> 

if it's just for a custom case (as it sounds like).. a simple small
change to the pagefault handler sounds like the easiest thing to do...
(eg just a direct function call to what would have been your notifier)

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Need help with register_page_fault_notifier() replacement in 2.6.24

[Pavel Roskin]

Quoting Arjan van de Ven <arjan@infradead.org>:

> if it's just for a custom case (as it sounds like).. a simple small
> change to the pagefault handler sounds like the easiest thing to do...
> (eg just a direct function call to what would have been your notifier)

Thanks!  Actually, the idea is to make it easy many people to run the  
trace without having them to patch or downgrade their kernels.  Also,  
it would be convenient for ath5k developers to run (and perhaps  
improve) the trace on the current development kernel.

Also, the code was lifted from some nvidia debugging tool, so the  
improved code could be contributed back there.

I guess if there is no simple answer, I'll have to try a few crazy  
ideas.  If nothing works, the fault handler chain could be reinstated,  
perhaps as a separate configuration option.

-- 
Regards,
Pavel Roskin

Re: Need help with register_page_fault_notifier() replacement in 2.6.24

[Arjan van de Ven]

On Mon, 19 Nov 2007 00:29:46 -0500
Pavel Roskin <proski@gnu.org> wrote:

> Quoting Arjan van de Ven <arjan@infradead.org>:
> 
> > if it's just for a custom case (as it sounds like).. a simple small
> > change to the pagefault handler sounds like the easiest thing to
> > do... (eg just a direct function call to what would have been your
> > notifier)
> 
> Thanks!  Actually, the idea is to make it easy many people to run
> the trace without having them to patch or downgrade their kernels.
> Also, it would be convenient for ath5k developers to run (and
> perhaps improve) the trace on the current development kernel.
> 
> Also, the code was lifted from some nvidia debugging tool, so the  
> improved code could be contributed back there.
> 
> I guess if there is no simple answer, I'll have to try a few crazy  
> ideas.  If nothing works, the fault handler chain could be
> reinstated, perhaps as a separate configuration option.

a generic "IO trace"  function (as config
option) sounds actually like a good idea... that could do a direct call
if the config option is enabled (as well as some sysctl thing I
suspect, so that you can turn it on and off as you want)... I would
entirely support one of those going to mainline.

The problem with a chain is that those are quite expensive to run, and
page faults should really be a fast operation... so the normal case
should be a light as possible.

> 


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org