Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 13 Jan 2023 14:59:51 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: [PATCH] selftests/ftrace: Extend multiple_kprobes.tc to add
 multiple consecutive probes in a function
To:     Masami Hiramatsu <mhiramat@kernel.org>
Cc:     Akanksha J N <akanksha@linux.ibm.com>,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-trace-kernel@vger.kernel.org, rostedt@goodmis.org,
        shuah@kernel.org
References: <20230112095600.37665-1-akanksha@linux.ibm.com>
        <1673529279.3c5f8oes3z.naveen@linux.ibm.com>
        <20230113005153.c6ca2f75b9d12627eb63308a@kernel.org>
In-Reply-To: <20230113005153.c6ca2f75b9d12627eb63308a@kernel.org>
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1673601511.tq30r5phea.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Masami Hiramatsu wrote:
> On Thu, 12 Jan 2023 18:51:14 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>=20
>> 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.
>=20
> 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,=20
vanilla trap-based kprobes as well as optprobes to ensure all of those=20
and their interactions are good.

>=20
>  - This is a test case for checking multiple (at least 256) kprobe events
>   can be defined and enabled.
>=20
>  - If you want to check the ftrace-based kprobe, it should be near the
>    function entry, maybe within 16 bytes or so.
>=20
>  - Also, you don't need to enable it at once (and should not for this cas=
e).
>=20
>> > The '|| true' is added with the echo statement to ignore errors that a=
re
>> > caused by trying to add kprobes to non probeable lines and continue wi=
th
>> > the test.
>=20
> Can you add another test case for that? (and send it to the MLs which Cc'd
> to this mail)
> e.g.=20
>=20
>    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=20
under the purview of multiple_kprobes.tc, but it can be split into a=20
separate multiple_kprobes_func.tc if you think that will be better.

>=20
>=20
> BTW, after we introduce the fprobe event (https://lore.kernel.org/linux-t=
race-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

>=20
> Thank you,
>=20
>> >=20
>> > Signed-off-by: Akanksha J N <akanksha@linux.ibm.com>
>> > ---
>> >  .../selftests/ftrace/test.d/kprobe/multiple_kprobes.tc        | 4 ++++
>> >  1 file changed, 4 insertions(+)
>>=20
>> Thanks for adding this test!
>>=20
>> >=20
>> > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kpr=
obes.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
>> >=20
>> > +for i in `seq 0 255`; do
>> > +  echo p $FUNCTION_FORK+${i} >> kprobe_events || true
>> > +done
>> > +
>> >  cat kprobe_events >> $testlog
>> >=20
>> >  echo 1 > events/kprobes/enable
>>=20
>> Thinking about this more, I wonder if we should add an explicit fork=20
>> after enabling the events, similar to kprobe_args.tc:
>> 	( echo "forked" )
>>=20
>> 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>
>>=20
>>=20
>> - Naveen
>=20
>=20
> --=20
> Masami Hiramatsu (Google) <mhiramat@kernel.org>
>=20