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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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



BTW, after we introduce the fprobe event (https://lore.kernel.org/linux-trace-kernel/166792255429.919356.14116090269057513181.stgit@devnote3/) that test case may be
update to check fprobe events.

Indeed, I suppose that can be a separate test.


Thanks,
Naveen


Thank you,

> > Signed-off-by: Akanksha J N <akanksha@xxxxxxxxxxxxx>
> ---
>  .../selftests/ftrace/test.d/kprobe/multiple_kprobes.tc        | 4 ++++
>  1 file changed, 4 insertions(+)

Thanks for adding this test!

> > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> index be754f5bcf79..f005c2542baa 100644
> --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
> @@ -25,6 +25,10 @@ if [ $L -ne 256 ]; then
>    exit_fail
>  fi
> > +for i in `seq 0 255`; do
> +  echo p $FUNCTION_FORK+${i} >> kprobe_events || true
> +done
> +
>  cat kprobe_events >> $testlog
> > echo 1 > events/kprobes/enable

Thinking about this more, I wonder if we should add an explicit fork after enabling the events, similar to kprobe_args.tc:
	( echo "forked" )

That will ensure we hit all the probes we added. With that change:
Acked-by: Naveen N. Rao <naveen.n.rao@xxxxxxxxxxxxxxxxxx>


- Naveen


--
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux