From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
Kan Liang <kan.liang@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH] perf lock contention: Change stack_id type to s32
Date: Mon, 12 Aug 2024 14:05:09 -0300 [thread overview]
Message-ID: <ZrpAxUEnCUNBcwCS@x1> (raw)
In-Reply-To: <CAM9d7ch1ESEhJW-1j0O-0xxr-w1we+opD1xWTs4Eq=u7Gg7unQ@mail.gmail.com>
On Mon, Aug 12, 2024 at 09:57:27AM -0700, Namhyung Kim wrote:
> On Mon, Aug 12, 2024 at 9:52 AM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > On Mon, Aug 12, 2024 at 01:09:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > > On Sat, Aug 10, 2024 at 12:17:04PM -0700, Namhyung Kim wrote:
> > > > The bpf_get_stackid() helper returns a signed type to check whether it
> > > > failed to get a stacktrace or not. But it saved the result in u32 and
> > > > checked if the value is negative.
> > > >
> > > > 376 if (needs_callstack) {
> > > > 377 pelem->stack_id = bpf_get_stackid(ctx, &stacks,
> > > > 378 BPF_F_FAST_STACK_CMP | stack_skip);
> > > > --> 379 if (pelem->stack_id < 0)
> > > >
> > > > ./tools/perf/util/bpf_skel/lock_contention.bpf.c:379 contention_begin()
> > > > warn: unsigned 'pelem->stack_id' is never less than zero.
> > > >
> > > > Let's change the type to s32 instead.
> > > >
> > > > Fixes: 6d499a6b3d90 ("perf lock: Print the number of lost entries for BPF")
> > >
> > > Thanks, applied to perf-tools-next,
> >
> > I'll try to fix this later, but now it fails the first 'make -C
> > tools/perf build-test' target, that you can run directly as:
> >
> > ⬢[acme@toolbox perf-tools-next]$ tools/perf/tests/perf-targz-src-pkg tools/perf
> > <SNIP>
> > CLANG /tmp/tmp.FRZLVEwqdz/perf-6.11.0-rc2/tools/perf/util/bpf_skel/.tmp/augmented_raw_syscalls.bpf.o
> > In file included from util/bpf_skel/lock_contention.bpf.c:9:
> > util/bpf_skel/lock_data.h:10:2: error: unknown type name 's32'; did you mean 'u32'?
> > 10 | s32 stack_id;
> > | ^~~
> > | u32
> > util/bpf_skel/vmlinux.h:17:15: note: 'u32' declared here
> > 17 | typedef __u32 u32;
> > | ^
>
> Oops, sorry about this. There was a kernel test robot report.
Cool, I didn't see it, but its good its doing this work.
> It seems we need 'typedef __s32 s32;' too.
Please send a v2 then,
Thanks,
- Arnaldo
> Thanks,
> Namhyung
>
>
> > In file included from util/bpf_skel/lock_contention.bpf.c:9:
> > util/bpf_skel/lock_data.h:14:2: error: unknown type name 's32'; did you mean 'u32'?
> > 14 | s32 stack_id;
> > | ^~~
> > | u32
> > util/bpf_skel/vmlinux.h:17:15: note: 'u32' declared here
> > 17 | typedef __u32 u32;
> > | ^
> > 2 errors generated.
> > make[2]: *** [Makefile.perf:1247: /tmp/tmp.FRZLVEwqdz/perf-6.11.0-rc2/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > make[1]: *** [Makefile.perf:292: sub-make] Error 2
> > make: *** [Makefile:76: all] Error 2
> > make: Leaving directory '/tmp/tmp.FRZLVEwqdz/perf-6.11.0-rc2/tools/perf'
> > ⬢[acme@toolbox perf-tools-next]$
next prev parent reply other threads:[~2024-08-12 17:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 12:29 [bug report] perf lock: Print the number of lost entries for BPF Dan Carpenter
2024-08-10 19:17 ` [PATCH] perf lock contention: Change stack_id type to s32 Namhyung Kim
2024-08-12 14:52 ` kernel test robot
2024-08-12 16:09 ` Arnaldo Carvalho de Melo
2024-08-12 16:52 ` Arnaldo Carvalho de Melo
2024-08-12 16:57 ` Namhyung Kim
2024-08-12 17:05 ` Arnaldo Carvalho de Melo [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-08-11 18:24 kernel test robot
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=ZrpAxUEnCUNBcwCS@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=dan.carpenter@linaro.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.