BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Emil Tsalapatis" <emil@etsalapatis.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 5/7] selftests/bpf: Test local IRQ kfunc inlining
Date: Tue, 27 Oct 2026 16:46:10 +0000	[thread overview]
Message-ID: <sashiko-outbox-186949@kernel.org> (raw)
In-Reply-To: <20261027162820.10887-6-emil@etsalapatis.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] selftests/bpf: parallel race on bpf_jit_harden in test_irq_jit()
- [Medium] selftests/bpf: missing is_jit_enabled() skip check in test_irq_jit()
--

commit c1826dafea259f7db660c28b5f90f57c88d53332
Author: Emil Tsalapatis <emil@etsalapatis.com>

selftests/bpf: Test local IRQ kfunc inlining

This commit adds BPF selftests for local IRQ save and restore kfunc inlining,
checking that userspace cannot submit the kernel-private opcodes directly and
verifying the translated and JITed instructions with bpf_jit_harden enabled.

> diff --git a/tools/testing/selftests/bpf/prog_tests/irq_jit.c b/tools/testing/selftests/bpf/prog_tests/irq_jit.c
> new file mode 100644
> index 0000000000000..3d5dc3c77edbc
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/irq_jit.c

[ ... ]

> +void test_irq_jit(void)
> +{
> +	struct irq_jit *skel;
> +	const char *harden = "/proc/sys/net/core/bpf_jit_harden";
> +	char old_harden[32];
> +	int err;

[Severity: Medium]
Should test_irq_jit() be declared as serial_test_irq_jit() instead?

Because /proc/sys/net/core/bpf_jit_harden modifies the global bpf_jit_harden
sysctl rather than per-netns state, running test_irq_jit() in parallel mode
(test_progs -j) enables constant blinding and disables BPF kallsyms globally
while other worker processes are running.

Concurrent tests that assert on unblinded xlated instruction offsets (such as
check_one_to_one_mapping(), check_simple(), and check_deletions() in
tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c) or look up JITed BPF
symbols in /proc/kallsyms (such as test_stacktrace_ips) can fail spuriously
while bpf_jit_harden is set to 2.

In addition, test_irq_jit() races with other parallel tests that read and
write bpf_jit_harden (such as toggle_jit_harden() in
tools/testing/selftests/bpf/prog_tests/subprogs.c and check_blindness() in
tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c). A concurrent writer
can clear bpf_jit_harden before irq_jit__open_and_load() runs, or cause
old_harden to sample and restore "2", leaving hardening permanently enabled
for subsequent tests like serial_test_btf_rust().

Other tests that set /proc/sys/net/core/bpf_jit_harden to "2" via
sysctl_set_or_fail(), such as serial_test_arena_scalar_blinded(),
serial_test_jit_insns_blinded(), and serial_test_kasan(), use the
serial_test_ prefix to avoid this race.

> +
> +	if (sysctl_set_or_fail(harden, old_harden, "2"))
> +		return;
> +	skel = irq_jit__open_and_load();
> +	if (!ASSERT_OK_PTR(skel, "irq_jit_open_and_load"))
> +		goto restore_harden;

[Severity: Medium]
What happens in test_irq_jit() when the kernel is built without
CONFIG_BPF_JIT or when the BPF JIT is disabled at runtime
(/proc/sys/net/core/bpf_jit_enable == 0)?

When CONFIG_BPF_JIT is not enabled, /proc/sys/net/core/bpf_jit_harden does
not exist and sysctl_set_or_fail() fails the test with ENOENT. When the JIT
is compiled in but disabled at runtime, add_kfunc_call() in
kernel/bpf/verifier.c rejects the kfunc calls with -ENOTSUPP:

    if (!env->prog->jit_requested) {
        verbose(env, "JIT is required for calling kernel function\n");
        return -ENOTSUPP;
    }

causing irq_jit__open_and_load() to fail the test instead of skipping.

Could test_irq_jit() check is_jit_enabled() and call test__skip() before
touching bpf_jit_harden, similar to serial_test_arena_scalar_blinded() in
tools/testing/selftests/bpf/prog_tests/arena_scalar_blinded.c:

    if (!is_jit_enabled()) {
        test__skip();
        return;
    }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027162820.10887-1-emil@etsalapatis.com?part=5

  reply	other threads:[~2026-10-27 16:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 16:28 [PATCH bpf-next 0/7] bpf: Inline IRQ enter/exit instructions Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 1/7] bpf: Add internal IRQ save and restore instructions Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 2/7] x86, bpf: JIT " Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 3/7] arm64, " Emil Tsalapatis
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:28 ` [PATCH bpf-next 4/7] bpf: Inline local IRQ kfunc calls during verifier fixup Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 5/7] selftests/bpf: Test local IRQ kfunc inlining Emil Tsalapatis
2026-10-27 16:46   ` sashiko-bot [this message]
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:28 ` [PATCH bpf-next 6/7] bpf: Enable fastcall for inlined local IRQ kfuncs Emil Tsalapatis
2026-10-27 16:28 ` [PATCH bpf-next 7/7] selftests/bpf: Verify register preservation for IRQ fastcalls Emil Tsalapatis
2026-10-27 17:10   ` bot+bpf-ci
2026-10-27 16:53 ` [PATCH bpf-next 0/7] bpf: Inline IRQ enter/exit instructions Alexei Starovoitov
2026-10-28  1:55   ` Emil Tsalapatis
2026-10-28 16:56     ` Kumar Kartikeya Dwivedi

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=sashiko-outbox-186949@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=emil@etsalapatis.com \
    --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