On Wednesday 07 January 2015 06:40 PM, William Cohen wrote:
On 01/07/2015 07:07 AM, Pratyush Anand wrote:
> Hi Will,
> On Monday 05 January 2015 09:36 PM, William Cohen wrote:
>> Hi All,
>> Pratyush has been implementing uprobes support for aarch64 and has
>> posted a set of patches
>> review. The really new Linux kernels requires a patch to the
>> systemtap runtime because the f_dentry macro has been removed. With
>> the patched systemtap I was able to run the systemtap testsuite and
>> get some test results exercising the uprobes support:
>> There looked to be a localized fixes for plt support to eliminate the
>> unsupported systemtap.base/list.exp plt-* tests.
>> A number of the tests appear to fail because of userspace arguments
>> cannot be found for sdt probes.
>> The uprobe patches still need some refinement. On a number of
>> systemtap "make installcheck" runs the kernel would get stuck spewing
>> Unexpected kernel single-step exception at EL1
> There are at least two functions of arm64/uprobe implementation
uprobe_breakpoint_handler and uprobe_single_step_handler, where a kprobe insertion might
be causing above issue. Currently I have qualified these functions with __kprobe, so that
one can not insert a kprobe there. With this you should not be able to see the above
> However, I am still investigating if a kprobe insertion be allowed to these functions
or any other function which is called directly from debug exception handler
Are there any other places that need to be protected from kprobe probing in the arm64
yes, I tried inserting kprobe in
arch/arm64/kernel/debug-monitors.c:brk_handler and it failed. So, I
think as of now, we can not probe any function which comes in the path
Looking into kprobe code, it seems that it allows REENTER, so it should
have worked. Do not have much idea at present. Still, studying these
part of code.
> Update code is here:
I will give the new kernel a try.
>> However, things are looking better for user-space probing on arm64.