(2013/11/12 19:55), Sandeepa Prabhu wrote:
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 :-)
Nice :)
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!.
On x86, I can probe memcpy() safely. It depends on the kprobes (and breakpoint handling) implementation, and it could be found.
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 ?
I see, the blacklist still needs to be maintained. I periodically run a test for probing each function on my kernel, and if I found such problem, I added it on the blacklist. Currently I run the test only on x86, so perhaps, other arch does not have well tested yet.
Thank you,