Re: [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add multiple consecutive probes in a function

[Naveen N. Rao]

Masami Hiramatsu wrote:
> Hi Naveen,
>
> On Fri, 13 Jan 2023 14:59:51 +0530
> "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxxxxxxx> wrote:
>
> > Masami Hiramatsu wrote:
> > > On Thu, 12 Jan 2023 18:51:14 +0530
> > > "Naveen N. Rao" <naveen.n.rao@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
> >
> > 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.

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.

> 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 ? :)


Thanks,
Naveen