This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: can kprobes be modular?
- From: Roland McGrath <roland at redhat dot com>
- To: Jim Keniston <jkenisto at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Wed, 28 Feb 2007 18:14:06 -0800 (PST)
- Subject: Re: can kprobes be modular?
> Well, there's at least one call to kprobes from deep in the kernel:
> finish_task_switch() calls kprobe_flush_task().
Ah, that's the kind of gotcha I was looking for. This appears to be just
a destructor hook for task-associated data when a task_struct is cleaned
up. I don't see a strong reason why it needs to be done in
finish_task_switch rather than later like in __put_task_struct (which is
after a zombie is reaped, but that isn't usually forever). With
CONFIG_PROFILING=y, task_handoff_register is already exported and can be
used for that.
> There may be other gotchas. As far as I know, nobody has investigated
> the idea for quite a while.
For now I'm just seeking all the concrete gotchas people can think of. I
haven't seen a concrete issue so far that didn't seem trivially addressed
in a cleaner and more modular fashion than #ifdef CONFIG_KPROBES.
Thanks,
Roland