RE: instrumenting vs. module loading

["Lynch, Rusty" <rusty dot lynch at intel dot com>]

>Lynch, Rusty wrote:
>>>Ananth N Mavinakayanahalli wrote:
>>>
>>>>Ananth N Mavinakayanahalli wrote:
>>>>
>>>>
>>>>>Frank Ch. Eigler wrote:
>>>>>
>>>>>I don't have much idea about in kernel details of module loading
and
>>>>>unloading, but I'd imagine we'll encounter "interesting" issues if
a
>>>>>different module is loaded in the same text range with such a stray
>>>>>kprobe.
>>>>
>>>>
>>>>On more thought, we won't see any such issues - we won't have the
>>>>breakpoint hit at all - the whole text gets overlaid right?
>>>>
>>>>Doh! what was I thinking earlier.. need more coffee :-)
>>>>
>>>>Ananth
>>>>
>>>>
>>>>
>>>
>>>All is fine until the clean up code tries to unregister the kprobe
and
>>>it scribbles over that location in memory which no longer has the
>>>breakpoint.
>>>
>>>-will
>>
>>
>> Or... the same memory is used to load a new module, and we end up
>> replacing an instruction with the old original instruction.  Can you
>> imagine if that didn't trigger a crash, but just some very subtle
bug.
>>
>> I think this could be solved in the unregistration.
>>
>
>Yeah.. something like:
>
>if (*addr != BREAKPOINT_INSTRUCTION)
>	/* just unlink the kprobe from hlist */
>
>should do the trick.
>
>I know systemtap scripts would probably handle it at a higher layer,
but
>we'd need this test anyway to protect ourselves from a joe-user with
bad
>intentions.
>
>Ananth

Another idea could be that when we register a kprobe, we check to see if
the address space is in the module address space.  If it is then add a
dependency on that module, and then release that dependency after the
kprobe is removed.  This would make the module unloader refuse to unload
the module while we have it instrumented (like if you try to unload your
network driver while your network is up.)

    --rusty