From: sashiko-bot@kernel.org
To: "Gabriele Monaco" <gmonaco@redhat.com>
Cc: linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v2 11/15] tools/rv: Define CONFIG_X86_64 statically for BPF monitors
Date: Thu, 01 Oct 2026 15:49:14 +0000 [thread overview]
Message-ID: <20261001154915.07D291F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001152042.124445-12-gmonaco@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rv: build failure from #ifdef inside LIBBPF_OPTS macro
--
commit a53c9f566aefb8c15a1d5a3745ce6829be8b1a7a
Author: Gabriele Monaco <gmonaco@redhat.com>
tools/rv: Define CONFIG_X86_64 statically for BPF monitors
This commit statically defines the CONFIG_X86_64 value via libbpf open
options to bypass system Kconfig dependencies. This ensures reliable
loading for the rv tool by defining the architecture at compile time.
> diff --git a/tools/verification/rv/src/bpf_monitor.c b/tools/verification/rv/src/bpf_monitor.c
> index 9a3f00febfeb2..d43ee75d3904f 100644
> --- a/tools/verification/rv/src/bpf_monitor.c
> +++ b/tools/verification/rv/src/bpf_monitor.c
> @@ -719,7 +719,16 @@ static struct bpf_object *open_bpf_monitor(const char *path, struct bpf_monitor_
> struct bpf_object *obj = NULL;
> int res;
>
> - obj = bpf_object__open_file(path, NULL);
> + LIBBPF_OPTS(bpf_object_open_opts, opts,
> + /* Define statically as arch is known, Kconfig may not be available */
> +#ifdef __x86_64__
> + .kconfig = "CONFIG_X86_64=y\n",
> +#else
> + .kconfig = "CONFIG_X86_64=n\n",
> +#endif
> + );
[Severity: Low]
Does this #ifdef block inside the LIBBPF_OPTS macro invocation cause a
build failure?
Embedding preprocessor directives inside macro arguments invokes undefined
behavior according to the C99 standard. Clang explicitly rejects this
pattern (-Wembedded-directive), which leads to a build failure when
compiling tools/rv with Clang.
> +
> + obj = bpf_object__open_file(path, &opts);
> if (!obj) {
> err_msg("bpf: error opening object: %s\n", strerror(errno));
> return NULL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261001152042.124445-1-gmonaco@redhat.com?part=11
next prev parent reply other threads:[~2026-10-01 15:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 15:20 [PATCH v2 00/15] rv: Add support for BPF monitors Gabriele Monaco
2026-10-01 15:20 ` [PATCH v2 01/15] sched: Add task enqueue/dequeue trace points Gabriele Monaco
2026-10-01 15:49 ` Peter Zijlstra
2026-10-02 7:09 ` Gabriele Monaco
2026-10-02 10:29 ` Peter Zijlstra
2026-10-02 11:55 ` Gabriele Monaco
2026-10-02 19:18 ` Peter Zijlstra
2026-10-02 19:40 ` Gabriele Monaco
2026-10-04 7:57 ` Steven Rostedt
2026-10-04 7:45 ` Steven Rostedt
2026-10-02 0:42 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 02/15] tools/rv: Skip empty pid error in selftest if command failed Gabriele Monaco
2026-10-02 0:42 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 03/15] rv: Refactor da_trace() functions to get strings internally Gabriele Monaco
2026-10-01 15:20 ` [PATCH v2 04/15] rv: Cast result of model_get_*_name() Gabriele Monaco
2026-10-01 15:20 ` [PATCH v2 05/15] tools/rv: Move argument parsing from in_kernel to utils Gabriele Monaco
2026-10-02 0:25 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 06/15] tools/build: Add a feature test for bpftool-btf Gabriele Monaco
2026-10-01 15:20 ` [PATCH v2 07/15] tools/rv: Implement BPF monitor discovery and listing Gabriele Monaco
2026-10-01 15:40 ` sashiko-bot
2026-10-02 0:42 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 08/15] tools/rv: Implement BPF monitor loading and tracing Gabriele Monaco
2026-10-01 15:41 ` sashiko-bot
2026-10-02 0:43 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 09/15] tools/rv: Copy stripped bpf_atomic.h from libarena Gabriele Monaco
2026-10-02 0:42 ` bot+bpf-ci
2026-10-07 12:59 ` Nam Cao
2026-10-08 9:00 ` Gabriele Monaco
2026-10-08 11:16 ` Nam Cao
2026-10-01 15:20 ` [PATCH v2 10/15] tools/rv: Add BPF monitors Gabriele Monaco
2026-10-01 15:55 ` sashiko-bot
2026-10-02 0:43 ` bot+bpf-ci
2026-10-06 13:29 ` Alexei Starovoitov
2026-10-08 9:54 ` Gabriele Monaco
2026-10-01 15:20 ` [PATCH v2 11/15] tools/rv: Define CONFIG_X86_64 statically for " Gabriele Monaco
2026-10-01 15:49 ` sashiko-bot [this message]
2026-10-01 15:20 ` [PATCH v2 12/15] tools/rv: Add reactors support to " Gabriele Monaco
2026-10-01 15:57 ` sashiko-bot
2026-10-02 0:43 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 13/15] verification/rvgen: Add support for " Gabriele Monaco
2026-10-02 0:25 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 14/15] tools/rv: Add selftest for rv bpf monitors Gabriele Monaco
2026-10-01 16:03 ` sashiko-bot
2026-10-02 0:43 ` bot+bpf-ci
2026-10-01 15:20 ` [PATCH v2 15/15] verification/rvgen: Add selftest for rvgen -b Gabriele Monaco
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=20261001154915.07D291F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=gmonaco@redhat.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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