[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNMehFp7dM7QhR7AQgp33i-a0s0R-J9ZPweyroY45eCizQ@mail.gmail.com>
Date: Fri, 8 Dec 2023 09:06:33 +0100
From: Marco Elver <elver@...gle.com>
To: Kyle Huey <me@...ehuey.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>,
Kyle Huey <khuey@...ehuey.com>, linux-kernel@...r.kernel.org,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>,
"Robert O'Callahan" <robert@...llahan.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Mykola Lysenko <mykolal@...com>,
Shuah Khan <shuah@...nel.org>, bpf@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 3/3] selftest/bpf: Test a perf bpf program that
suppresses side effects.
On Fri, 8 Dec 2023 at 02:08, Kyle Huey <me@...ehuey.com> wrote:
>
> On Thu, Dec 7, 2023 at 2:56 PM Kyle Huey <me@...ehuey.com> wrote:
> >
> > On Thu, Dec 7, 2023 at 11:20 AM Marco Elver <elver@...gle.com> wrote:
> > >
> > > On Thu, 7 Dec 2023 at 20:12, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> > > >
> > > > On Thu, Dec 7, 2023 at 8:35 AM Kyle Huey <me@...ehuey.com> wrote:
> > > > >
> > > > > The test sets a hardware breakpoint and uses a bpf program to suppress the
> > > > > side effects of a perf event sample, including I/O availability signals,
> > > > > SIGTRAPs, and decrementing the event counter limit, if the ip matches the
> > > > > expected value. Then the function with the breakpoint is executed multiple
> > > > > times to test that all effects behave as expected.
> > > > >
> > > > > Signed-off-by: Kyle Huey <khuey@...ehuey.com>
> > > > > ---
> > > > > .../selftests/bpf/prog_tests/perf_skip.c | 145 ++++++++++++++++++
> > > > > .../selftests/bpf/progs/test_perf_skip.c | 15 ++
> > > > > 2 files changed, 160 insertions(+)
> > > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_skip.c
> > > > > create mode 100644 tools/testing/selftests/bpf/progs/test_perf_skip.c
> > > > >
> > > > > diff --git a/tools/testing/selftests/bpf/prog_tests/perf_skip.c b/tools/testing/selftests/bpf/prog_tests/perf_skip.c
> > > > > new file mode 100644
> > > > > index 000000000000..f6fa9bfd9efa
> > > > > --- /dev/null
> > > > > +++ b/tools/testing/selftests/bpf/prog_tests/perf_skip.c
> > > > > @@ -0,0 +1,145 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +#define _GNU_SOURCE
> > > > > +
> > > > > +/* We need the latest siginfo from the kernel repo. */
> > > > > +#include <asm/siginfo.h>
> > > >
> > > > selftests are built with UAPI headers' copies under tools/include, so
> > > > CI did catch a real issue, I think. Try copying
> > > > include/uapi/asm-generic/siginfo.h into
> > > > tools/include/uapi/asm-generic/siginfo.h ?
> > >
> > > I believe parts of this were inspired by
> > > tools/testing/selftests/perf_events/sigtrap_threads.c - getting the
> > > kernel headers is allowed, as long as $(KHDR_INCLUDES) is added to
> > > CFLAGS. See tools/testing/selftests/perf_events/Makefile. Not sure
> > > it's appropriate for this test though, if you don't want to add
> > > KHDR_INCLUDES for everything.
> >
> > Yes, that's right. Namhyung's commit message for 91c97b36bd69 leads me
> > to believe that I should copy siginfo.h over into tools/include and
> > fix the perf_events self tests too.
> >
> > - Kyle
>
> That doesn't really help (though perhaps it should be done anyway so
> the selftests aren't reaching into include/) because the glibc headers
> still redefine a ton of stuff in asm-generic/siginfo.h.
>From what I can see your test doesn't actually refer to any of the
si_perf_* fields, but only needs it for this:
> + ASSERT_EQ(info->si_code, TRAP_PERF, "wrong si_code");
I think that's easy to fix by just defining TRAP_PERF yourself or
leaving out the assert completely. If you get an unexpected SIGTRAP
your asserts checking sigtrap_count elsewhere will fail, too. It'd
just be harder to debug.
Powered by blists - more mailing lists