On 12 November 2013 15:47, Masami Hiramatsu masami.hiramatsu.pt@hitachi.com wrote:
(2013/11/12 17:44), Sandeepa Prabhu wrote:
On 12 November 2013 12:57, Masami Hiramatsu masami.hiramatsu.pt@hitachi.com wrote:
(2013/11/12 15:23), Sandeepa Prabhu wrote:
> OK, I've ensured that the hw_breakpoint (from perf) can work > with kprobes (from ftrace) at the same address on x86. > So if arm64 already support hw_breakpoint on perf, kprobes should > work with it.
Single-stepping on x86 is different to the step behaviour on arm64 afaik. On ARM, we have to manually remove the breakpoint, perform a single-step, then add the breakpoint again. If we re-enable debug exceptions in the kprobe handler, the step will complete early and we'll never step off the breakpoint.
I'm unsure about arm64's debug feature behavior, what does happen when it performs a single-step on sw-breakpoint?
Sandeepa: I think you need to retry Masami's test on the arm64 model, since I'm fairly sure it won't work as expected without some additional code.
OK, anyway, for testing same one, we need to port ftrace first. So the next
Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module can be done without ftrace port.
Yes, got it, all my verification until now are done using sample modules only, looking out for perf (or some other mechanism: ptrace?) that uses v8 hw breakpoint.
Yes, kprobe vs. perf and uprobe vs. ptrace :)
plan is to make a kprobe module to put a probe (which just printk something) on a specific function (e.g. vfs_symlink), and run perf record with hw-breakpoint as below
$ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
Note that 0xXXXXXX is the address of vfs_symlink.
After that, you can see the message in dmesg and also check the perf result with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if it works)
Thanks for steps, ARM64 ftrace patches are under review on arm mailing list, I can contact the (linaro) developer implementing ftrace on what's supported and then figure-out a way to test this concurrency of kprobes breakpoint and hardware breakpoint.
Would you mean this? :) http://www.spinics.net/lists/arm-kernel/msg278477.html
Wow, it seems that this also has some works around instruction manipulation (and confusable filenames...)
I referred to: http://lwn.net/Articles/572323/ which is another implementation and on LAKML
OK, I'll check that (and looks good at a glance). By the way, I concern about Linaro guys who looks working a bit far from the LKML and original feature maintainers. Please contact them, I'm sure they don't bite your hand :)
Hmm sure, will convey to our developers/leads :-)
BTW, I'm currently trying a general housecleaning of __kprobes annotations. It may also have impact on your patch. https://lkml.org/lkml/2013/11/8/187
Hmm, we can help testing your patchset on arm64 platforms. Also have many doubts on the changes you are working [blacklisting probes etc]
Basically I had tried placing kprobe on memcpy() and the model hung (insmod never returned back!). Fast-model I have does not have option of any debug so no clue what happened!. memcpy() is low-level call being used internally within kprobes, so probably we cannot handle probe on that routine, but then how to make sure all such API are rejected by kprobe sub-system ?
~Sandeepa
Thank you,
-- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com