[PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support

[Masami Hiramatsu]

(2014/12/04 19:21), Steve Capper wrote:
> On 4 December 2014 at 02:48, David Long <dave.long at linaro.org> wrote:
>> On 12/03/14 20:16, William Cohen wrote:
>>
>> [...]
>>
>>>
>>> The perf issue seems to be independent and can be reproduced without using
>>> any kprobe support.  I need to get a simple reproducer and mention it on the
>>> linux-perf-user list.
>>>
>>> -Will
>>>
>>
>>
>> OK, my confusion came from all the different things perf can use.  I have
>> not yet been able to reproduce the "perf stat" failure, but I do see the
>> failure with Steve's example using tracepoints.  I had thought that was
>> using kprobes, but apparently it just uses tracepoints.  These look like two
>> different failures to me:  One related to tracepoints, and one in the PMU
>> driver.
>>
>> Since this seems unrelated to kprobes I don't plan on pursuing these
>> particular problems.
>>
>> -dl
>>
> 
> Sorry for the late reply...
> 
> The example I had was:
> echo "p:memcpy memcpy %x2" > /sys/kernel/debug/tracing/kprobe_events
> perf record -e kprobes:memcpy -a sleep 5
> 
> [then crash due to IRQs being unexpectedly disabled in the ext4 code]
> 
> Isn't that a kprobe problem?
> 

It should be a kprobe problem. As I mentioned, if you set a probe on
trace_event_buffer_lock_reserve() instead of memcpy(), the same problem
may happen without using perf. (It is enough enabling the new event to
reproduce the problem, I guess)

The problem what Will reported was different one. He used "perf stat"
which never touch the kprobes itself, and solved in newer kernel (as
he reported)

I'd like to ask you to try my fix on your machine, with my reproducing
methods. (do not use sytemtap nor perf, those can have other issues)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt at hitachi.com