Masami Hiramatsu <masami.hiramatsu...@hitachi.com> writes: >> I am unable to recreate this problem on a fedora system; hash_64 is >> inlined AFAICS.
Thanks testing. How does the disassembly of get_kprobes look for you? > I also tried and couldn't recreate hash_64 problem on my ubuntu 12.10. > Could you tell us your kconfig? Sure, see http://lindi.iki.fi/lindi/config-3.7-trunk-amd64_3.7.3-1~experimental.1 Note that I am doing the tests under xen. Should I redo the tests under kvm? >> This is a clear case of recursion. Either of the two options should fix >> the problem. > > I think __kprobes is better if it works, because it causes kprobes > issue (no problem in other parts). > (Again, since I can't reproduce this hash_64.constprop, > I'm not sure that __kprobes can fix that clearly.) Ok. My worry is that hash_64 is not the only function that is called from a __kprobes marked function. For example kprobes_module_callback calls mutex_lock. Should we also mark mutex_lock with __kprobes? Based on the disassembly of code between __kprobes_text_start and __kprobes_text_end I made a function call graph that shows functions that get called from this region: http://lindi.iki.fi/lindi/kprobes/function-call-graph1.png The __kprobes functions are marked with red color. I had to omit mutex_lock, mutex_unlock and printk from the graph to make it readable (I also omited functions that don't call other functions). As you can see, this is quite a minefield :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
