A kprobes user has asked for the ability to use kprobes to turn a specified function into a no-op. I couldn't figure out how to do that (Any ideas?), but it occurred to us that jprobes takes us partway there. Our user's request could be viewed as a special case of a more general feature: the ability to execute a jprobe-like handler instead of (rather than before) executing the probed function.
Subject: Re: New: jprobe variant to run handler instead of probed function On Fri, Jan 13, 2006 at 11:26:01PM -0000, jkenisto at us dot ibm dot com wrote: > A kprobes user has asked for the ability to use kprobes to turn a specified > function into a no-op. I couldn't figure out how to do that (Any ideas?), but > it occurred to us that jprobes takes us partway there. > > Our user's request could be viewed as a special case of a more general feature: > the ability to execute a jprobe-like handler instead of (rather than before) > executing the probed function. Probably just calling "return" instead of "jprobe_return" from the jprobe handler would do the trick ? I had that possibility at the back of my mind as a use of jprobes for fault injection purposes, but one would need to actually try it out to make sure it works (I hadn't really thought it through it in detail). Regards Suparna > > -- > Summary: jprobe variant to run handler instead of probed function > Product: systemtap > Version: unspecified > Status: NEW > Severity: enhancement > Priority: P3 > Component: kprobes > AssignedTo: systemtap at sources dot redhat dot com > ReportedBy: jkenisto at us dot ibm dot com > > > http://sourceware.org/bugzilla/show_bug.cgi?id=2152 > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee.
> Probably just calling "return" instead of "jprobe_return" from the jprobe > handler would do the trick ? You can't do that(at least in the current design) as jprobe_handler are executed with preempt disabled and current_kprobe set to this probe. Hence jprobe_handler() _must_ execute jprobe_return(), so that Kprobe code can reverse the preempt count and clear current_kprobe.
Subject: Re: jprobe variant to run handler instead of probed function On Mon, Jan 16, 2006 at 05:26:29PM -0000, anil dot s dot keshavamurthy at intel dot com wrote: > > ------- Additional Comments From anil dot s dot keshavamurthy at intel dot com 2006-01-16 17:26 ------- > > Probably just calling "return" instead of "jprobe_return" from the jprobe > > handler would do the trick ? > You can't do that(at least in the current design) as jprobe_handler are > executed with preempt disabled and current_kprobe set to this probe. Hence True. Thanks for spotting that. > jprobe_handler() _must_ execute jprobe_return(), so that Kprobe code can > reverse the preempt count and clear current_kprobe. > > > > -- > > > http://sourceware.org/bugzilla/show_bug.cgi?id=2152 > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee.
Created attachment 1560 [details] Patch to nop the function I developed the patch to nop the function for i386 and I executed the jprobe module and it was running properly. I need to test it rigorously, Please let me know comments on this. Thanks Srinivasa DS
Jprobe module should have jprobe_nop_retun in its function and "return" is also required. An example is here int jversion_read_proc(char *page, char **start, off_t off, int count, int *eof, void *data) { jprobe_nop_return(); return 0; } static struct jprobe my_jprobe = { .entry = JPROBE_ENTRY(jversion_read_proc) }; static int __init jprobe_init(void) { int ret; my_jprobe.kp.symbol_name = "version_read_proc"; if ((ret = register_jprobe(&my_jprobe)) <0) { printk("register_jprobe failed, returned %d\n", ret); return -1; } printk("Planted jprobe at %p, handler addr %p\n", my_jprobe.kp.addr, my_jprobe.entry); return 0; } static void __exit jprobe_exit(void) { unregister_jprobe(&my_jprobe); printk("jprobe unregistered\n"); } module_init(jprobe_init) module_exit(jprobe_exit) MODULE_LICENSE("GPL");
On the subject of dynamically replacing kernel functions, the following pointer, courtesy of Ananth 7/29/07, may be of interest. ----- Not sure if people paid attention to this posting last week on lkml: http://marc.info/?l=linux-kernel&m=118520894606855&w=2 The objective seems to be along the same lines as what is being thought of for concurrent driver updates and code patching as such. -----
Other ventures in this area include kreplace (http://lkml.indiana.edu/hypermail/linux/kernel/0811.2/02376.html) and ksplice.
Probably won't ever do this.