linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Akanksha J N <akanksha@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, mhiramat@kernel.org,
	rostedt@goodmis.org, shuah@kernel.org
Subject: Re: [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add multiple consecutive probes in a function
Date: Fri, 13 Jan 2023 00:51:53 +0900	[thread overview]
Message-ID: <20230113005153.c6ca2f75b9d12627eb63308a@kernel.org> (raw)
In-Reply-To: <1673529279.3c5f8oes3z.naveen@linux.ibm.com>

On Thu, 12 Jan 2023 18:51:14 +0530
"Naveen N. Rao" <naveen.n.rao@linux.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 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


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.

Thank you,

> > 
> > Signed-off-by: Akanksha J N <akanksha@linux.ibm.com>
> > ---
> >  .../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@linux.vnet.ibm.com>
> 
> 
> - Naveen


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

  reply	other threads:[~2023-01-12 16:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230112095600.37665-1-akanksha@linux.ibm.com>
2023-01-12 13:21 ` [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add multiple consecutive probes in a function Naveen N. Rao
2023-01-12 15:51   ` Masami Hiramatsu [this message]
2023-01-13  9:29     ` Naveen N. Rao
2023-01-13 15:21       ` Masami Hiramatsu
2023-01-16  8:32         ` Naveen N. Rao
2023-01-19 23:55           ` Masami Hiramatsu
2023-01-25  7:09             ` Naveen N. Rao
2023-01-28  1:16               ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230113005153.c6ca2f75b9d12627eb63308a@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=akanksha@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).