Need help with register_page_fault_notifier() replacement in 2.6.24 - Kernel

This is a discussion on Need help with register_page_fault_notifier() replacement in 2.6.24 - Kernel ; 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). ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Need help with register_page_fault_notifier() replacement in 2.6.24

  1. Need help with register_page_fault_notifier() replacement in 2.6.24

    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Need help with register_page_fault_notifier() replacement in 2.6.24

    On Sun, 18 Nov 2007 12:40:16 -0500
    Pavel Roskin 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Need help with register_page_fault_notifier() replacement in 2.6.24

    Quoting Arjan van de Ven :

    > 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Need help with register_page_fault_notifier() replacement in 2.6.24

    On Mon, 19 Nov 2007 00:29:46 -0500
    Pavel Roskin wrote:

    > Quoting Arjan van de Ven :
    >
    > > 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread