[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1674629944.vwzovyd4lk.naveen@linux.ibm.com>
Date: Wed, 25 Jan 2023 12:39:36 +0530
From: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Akanksha J N <akanksha@...ux.ibm.com>,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, rostedt@...dmis.org,
shuah@...nel.org
Subject: Re: [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add
multiple consecutive probes in a function
Hi Masami,
Masami Hiramatsu wrote:
>> >
>> > 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.
>
>>
>> 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.
>
>> > 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
Powered by blists - more mailing lists