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

[Steve Capper]

On 4 December 2014 at 10:43, Masami Hiramatsu
<masami.hiramatsu.pt@xxxxxxxxxxx> wrote:
> (2014/12/04 19:21), Steve Capper wrote:
>> On 4 December 2014 at 02:48, David Long <dave.long@xxxxxxxxxx> 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,

I tried the following commands:

echo "p:trace_event_buffer_lock_reserve
trace_event_buffer_lock_reserve" >
/sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
echo 1 > /sys/kernel/debug/tracing/events/sched/sched_process_exec/enable

The system appeared okay, I then cat'ed out:
# cat /sys/kernel/debug/tracing/kprobe_profile
   trace_event_buffer_lock_reserve                           25              25

I got similar output (i.e. no crashes) both with and without the
interrupt fix you recommended.

I'm not sure how to interpret this, please let me know if you would
like me to run any other tests?

(I did also try your proposed fix with perf + memcpy and that crashed
in a similar way as before).

Cheers,
--
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/