Message-Id: <20230120085554.ab4dc1b72990a4957c4c88e2@kernel.org>
Date:   Fri, 20 Jan 2023 08:55:54 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
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 Naveen,

On Mon, 16 Jan 2023 14:02:04 +0530
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:

> Masami Hiramatsu wrote:
> > Hi Naveen,
> > 
> > On Fri, 13 Jan 2023 14:59:51 +0530
> > "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:
> > 
> >> Masami Hiramatsu wrote:
> >> > On Thu, 12 Jan 2023 18:51:14 +0530
> >> > "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:
> >> > 
> >> >> Akanksha J N wrote:
> >> >> > Commit 97f88a3d723162 ("powerpc/kprobes: Fix null pointer reference in
> >> >> > arch_prepare_kprobe()") fixed a recent kernel oops that was caused as
> >> >> > ftrace-based kprobe does not generate kprobe::ainsn::insn and it gets
> >> >> > set to NULL.
> >> >> > Extend multiple kprobes test to add kprobes on first 256 bytes within a
> >> >> > function, to be able to test potential issues with kprobes on
> >> >> > successive instructions.
> >> > 
> >> > What is the purpose of that test? If you intended to add a kprobe events
> >> > with some offset so that it becomes ftrace-based kprobe, it should be
> >> > a different test case, because
> >> 
> >> This is a follow up to:
> >> http://lore.kernel.org/1664530538.ke6dp49pwh.naveen@linux.ibm.com
> >> 
> >> The intent is to add consecutive probes covering KPROBES_ON_FTRACE, 
> >> vanilla trap-based kprobes as well as optprobes to ensure all of those 
> >> and their interactions are good.
> > 
> > Hmm, that should be implemented for each architecture with specific
> > knowledge instead of random offset, so that we can ensure the kprobe
> > is on ftrace/optimized or using trap. Also, it should check the
> > debugfs/kprobes/list file.
> 
> ...
> 
> > 
> >> 
> >> > 
> >> >  - This is a test case for checking multiple (at least 256) kprobe events
> >> >   can be defined and enabled.
> >> > 
> >> >  - If you want to check the ftrace-based kprobe, it should be near the
> >> >    function entry, maybe within 16 bytes or so.
> >> > 
> >> >  - Also, you don't need to enable it at once (and should not for this case).
> >> > 
> >> >> > The '|| true' is added with the echo statement to ignore errors that are
> >> >> > caused by trying to add kprobes to non probeable lines and continue with
> >> >> > the test.
> >> > 
> >> > Can you add another test case for that? (and send it to the MLs which Cc'd
> >> > to this mail)
> >> > e.g. 
> >> > 
> >> >    for i in `seq 0 16`; do
> >> >      echo p:testprobe $FUNCTION_FORK+${i} >> kprobe_events || continue
> >> >      echo 1 > events/kprobes/testprobe/enable
> >> >      ( echo "forked" )
> >> >      echo 0 > events/kprobes/testprobe/enable
> >> >      echo > kprobe_events
> >> >    done
> >> 
> >> The current test to add multiple kprobes within a function also falls 
> >> under the purview of multiple_kprobes.tc, but it can be split into a 
> >> separate multiple_kprobes_func.tc if you think that will be better.
> >> 
> > 
> > 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.

> 
> 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. 

> > 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.)

Thank you,

> 
> 
> Thanks,
> Naveen
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>

Powered by blists - more mailing lists