On 12 November 2013 15:47, Masami Hiramatsu <masami.hiramatsu...@hitachi.com> wrote: > (2013/11/12 17:44), Sandeepa Prabhu wrote: >> On 12 November 2013 12:57, Masami Hiramatsu >> <masami.hiramatsu...@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...@hitachi.com > > -- 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/
