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:   Wed, 26 Apr 2023 16:31:46 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>
Subject: Re: [PATCH v2 2/2] selftests/ftrace: Add new test case which checks
 for optimized probes
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: <20230418095557.19061-1-akanksha@linux.ibm.com>
        <20230418095557.19061-3-akanksha@linux.ibm.com>
        <20230425091039.9fd523dfdf7be5e800bac4fe@kernel.org>
        <1682400251.pez54ergiy.naveen@linux.ibm.com>
        <20230425234125.51455711c4388481c13be5ad@kernel.org>
In-Reply-To: <20230425234125.51455711c4388481c13be5ad@kernel.org>
MIME-Version: 1.0
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1682506809.uus6y0ir3i.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Masami Hiramatsu wrote:
> On Tue, 25 Apr 2023 10:58:30 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.ibm.com> wrote:
>=20
>> Masami Hiramatsu wrote:
>> > On Tue, 18 Apr 2023 15:25:57 +0530
>> > Akanksha J N <akanksha@linux.ibm.com> wrote:
>> >=20
>> >> Add new test case kprobe_opt_types.tc which enables and checks
>> >> if each probe has been optimized in order to test potential issues wi=
th
>> >> optimized probes.
>> >> The '|| continue' is added with the echo statement to ignore errors t=
hat
>> >> are caused by trying to add kprobes to non probeable lines and contin=
ue
>> >> with the test.
>> >> Signed-off-by: Akanksha J N <akanksha@linux.ibm.com>
>> >> ---
>> >>  .../ftrace/test.d/kprobe/kprobe_opt_types.tc  | 34 +++++++++++++++++=
++
>> >>  1 file changed, 34 insertions(+)
>> >>  create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kpro=
be_opt_types.tc
>> >>=20
>> >> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_=
types.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc
>> >> new file mode 100644
>> >> index 000000000000..54e4800b8a13
>> >> --- /dev/null
>> >> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.t=
c
>> >> @@ -0,0 +1,34 @@
>> >> +#!/bin/sh
>> >> +# SPDX-License-Identifier: GPL-2.0-or-later
>> >> +# Copyright (C) 2023 Akanksha J N, IBM corporation
>> >> +# description: Register/unregister optimized probe
>> >> +# requires: kprobe_events
>> >> +
>> >> +case `uname -m` in
>> >> +x86_64)
>> >> +;;
>> >> +arm*)
>> >> +;;
>> >> +ppc*)
>> >> +;;
>> >> +*)
>> >> +  echo "Please implement other architecture here"
>> >> +  exit_unsupported
>> >> +esac
>> >> +
>> >> +DEFAULT=3D$(cat /proc/sys/debug/kprobes-optimization)
>> >> +echo 1 > /proc/sys/debug/kprobes-optimization
>> >> +for i in `seq 0 255`; do
>> >> +        echo  "p:testprobe $FUNCTION_FORK+${i}" > kprobe_events || c=
ontinue
>> >> +        echo 1 > events/kprobes/enable || continue
>> >> +        (echo "forked")
>> >> +        PROBE_TYPE=3D$(cat /sys/kernel/debug/kprobes/list | grep $FU=
NCTION_FORK | awk '{print $4}' | awk '{print substr($0,2,length($0)-2)}')
>> >=20
>> > I think we can make it simply;
>> >=20
>> > PROBE=3D$(grep $FUNCTION_FORK /sys/kernel/debug/kprobes/list)
>> >=20
>> >> +        echo 0 > events/kprobes/enable
>> >> +        echo > kprobe_events
>> >> +        if [ $PROBE_TYPE =3D "OPTIMIZED" ]; then
>> >=20
>> > and
>> >=20
>> > if echo $PROBE | grep -q OPTIMIZED; then
>> >=20
>> >> +                echo "$DEFAULT" >  /proc/sys/debug/kprobes-optimizat=
ion
>> >> +                exit_pass
>> >> +        fi
>> >> +done
>> >> +echo "$DEFAULT" >  /proc/sys/debug/kprobes-optimization
>> >> +echo "Done"
>> >=20
>> > Hmm, this test does NOT return any error. It always returns success.
>>=20
>> Good catch!
>>=20
>> > I understand that optimization may not be possible within 256 bytes
>> > from the beginning of the function.
>>=20
>> Is that true in practice? Looking at x86 and ppc64le, it looks like we=20
>> will almost always be able to optimize at least one of the instructions=20
>> within the first 256 bytes of kernel_clone(). That's one of the primary=20
>> purposes of this test.
>=20
> Yeah, usually it should not happen. But since we don't disassemble it,
> we can not ensure that. So this depends on the compiler at last.

Ok.

>=20
>>=20
>> Are there valid reasons why we may not be able to optimize instructions?
>=20
> For example, if the compiler starts inserting some checker instruction
> on each instruction boundary for security, it may prevent optimizing
> kprobes. Usually it should not happen (because it bloat up the kernel siz=
e)
> but we cannot deny the possibility of such new feature as an option
> in the future.
>=20
>>=20
>> > In that case, you can return
>> > "unresolved", and not echoing "Done" but the reason why it is
>> > unresolved.
>=20
> Even in that case, it can notify such case as "unresolved", then we
> can notice it. (something like WARN_ON)

Sure, exiting as "Unresolved" should help point out a potential issue=20
with optimizing probes, rather than labeling this as a failure.


Thanks,
Naveen