Hi Masami,

Masami Hiramatsu wrote:

quoted

quoted

Yes, please make it separate, this test case is for checking whether
the ftrace can define/enable/disable multiple kprobe events. Not for
checking kprobe with different types, nor checking interactions among
different types of kprobes.

(BTW, if you want to test optprobe on x86, you can not put the probes
 within the jump instruction (+5 bytes). It will unoptimize existing
 optimized kprobe in that case)

Ok, I can see why we won't be able to optimize any of the probes on x86 
with this approach. But, we should be able to do so on powerpc and arm, 
the only other architectures supporting OPTPROBES at this time. For x86, 
we may have to extend the test to check kprobes/list.

Are there any instruction type specific limitation on those arch for
using optprobe? I guess the 'call' (branch with link register) will not
able to be optimized because it leaves the trampoline address on the
stack.

Yes, at least on powerpc, we only optimize ALU instructions and do not 
optimize load/store instructions, among many others. This is the reason 
we try to put a probe uptil 256 offset into a function in the proposed 
test, which will almost certainly catch an instruction that can be 
optimized.

quoted

Crucially, I think trying to place a probe at each byte can still 
exercize interactions across KPROBES_ON_FTRACE and normal kprobes, so 
this test is still a good start. In addition, we get to ensure that 
kprobes infrastructure is rejecting placing probes at non-instruction 
boundaries.

The interfere between probes can be happen between kprobes and optprobe
(*only on x86*), but not with KPORBES_ON_FTRACE. The ftrace replaced NOP
will be handled as one instruction. 

Yes.

quoted

quoted

And do you really need to run "multiple" kprobes at once?
I think what you need is 'kprobe_opt_types.tc'.

Yes, enabling those probes is a good stress test to ensure we are only 
accepting valid probe locations.

multiple_kprobe_types.tc ? :)

Please don't mixed it with the concept of 'multiple' probe test.
It is different that
 - kprobes can put probes on each instruction boundary.
 - kprobes can allocate and enable multiple probes at the same time.

What the multiple_kprobes.tc tests is the latter one.
(This is the reason why it chooses different functions so as not to
 interfere with each other.)

Ok, I was coming from the point of view that both tests end up 
installing "multiple" kprobes, but I do see your point.

How about adding two new tests:
1. The same test as has been proposed in this thread: trying to add a 
kprobe at every byte within $FUNCTION_FORK upto an offset of 256 bytes. 
We can probably call it kprobe_insn_boundary.tc
2. A new test to ensure we can add different kprobe types 
(kprobe_opt_types.tc). This test will need to enable and check if each 
probe has been optimized or not and needs arch-specific knowledge so 
that we can take care of x86.

Would that be ok?


Thanks,
Naveen