lkml.org 
[lkml]   [2014]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -tip v8 10/26] kprobes/x86: Allow probe on some kprobe preparation functions
(2014/03/25 4:35), Steven Rostedt wrote:
> On Wed, 05 Mar 2014 20:59:53 +0900
> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>
>> There is no need to prohibit probing on the functions
>> used in preparation phase. Those are safely probed because
>> those are not invoked from breakpoint/fault/debug handlers,
>> there is no chance to cause recursive exceptions.
>>
>> Following functions are now removed from the kprobes blacklist.
>> can_boost
>> can_probe
>> can_optimize
>> is_IF_modifier
>> __copy_instruction
>> copy_optimized_instructions
>> arch_copy_kprobe
>> arch_prepare_kprobe
>> arch_arm_kprobe
>> arch_disarm_kprobe
>> arch_remove_kprobe
>
> Is there any possibility that the arm and disarm could cause issues if
> we have a probe in the middle of setting it?

No problem at least on x86, since we need to take a text_mutex for
arm/disarm, those must not be called from int3/debug interrupts.

> I guess not, but I just wanted to ask, as your test only tested the
> start of function and not the middle of it.

No I've not tested yet. OK, I'll test it and report.

Thank you,

>
> -- Steve
>
>
>> arch_trampoline_kprobe
>> arch_prepare_kprobe_ftrace
>> arch_prepare_optimized_kprobe
>> arch_check_optimized_kprobe
>> arch_within_optimized_kprobe
>> __arch_remove_optimized_kprobe
>> arch_remove_optimized_kprobe
>> arch_optimize_kprobes
>> arch_unoptimize_kprobe
>>
>
>


--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com




\
 
 \ /
  Last update: 2014-03-25 11:01    [W:0.648 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site