public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mykyta Yatsenko" <mykyta.yatsenko5@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v12 2/6] bpf: Add bpf_prog_run_array_sleepable()
Date: Wed, 22 Apr 2026 22:02:31 +0000	[thread overview]
Message-ID: <20260422220231.A8141C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260422-sleepable_tracepoints-v12-2-744bf0e3b311@meta.com>

Sashiko AI review found 1 potential issue(s):
- [Critical] Inverted RCU lock logic in bpf_prog_run_array_sleepable() causes use-after-free and 'sleeping in atomic' panics
--

commit bed1594e26a509b74cbf793566b3e03eca1cc31d
Author: Mykyta Yatsenko <yatsenko@meta.com>

bpf: Add bpf_prog_run_array_sleepable()

This commit adds a new function to run BPF program arrays on faultable
tracepoints. It includes per-program recursion checking for private stack
safety and identifies dummy placeholder programs by checking if the length
is zero.

> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index b4b703c90ca94..c909fee369c2d 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h

[ ... ]

> @@ -3079,6 +3079,56 @@ void bpf_dynptr_set_null(struct bpf_dynptr_kern *ptr);
>  void bpf_dynptr_set_rdonly(struct bpf_dynptr_kern *ptr);
>  void bpf_prog_report_arena_violation(bool write, unsigned long addr, unsigned long fault_ip);
>  
> +static __always_inline u32
> +bpf_prog_run_array_sleepable(const struct bpf_prog_array *array,
> +			     const void *ctx, bpf_prog_run_fn run_prog)
> +{

[ ... ]

> +		run_ctx.bpf_cookie = item->bpf_cookie;
> +
> +		if (prog->sleepable) {
> +			guard(rcu)();
> +			ret &= run_prog(prog, ctx);
> +		} else {
> +			ret &= run_prog(prog, ctx);
> +		}

Should the guard(rcu)() logic be inverted here? 

Sleepable BPF programs are permitted to block and sleep to handle page
faults, but holding the RCU read lock while sleeping is generally not
permitted and can lead to scheduling while atomic panics.

Conversely, executing non-sleepable BPF programs without the RCU read lock
could lead to use-after-free regressions, as they rely on the execution
environment holding the RCU lock to safely access RCU-protected memory and
dynamically sized maps.

Could this be changed to if (!prog->sleepable) to match the pattern used in
bpf_prog_run_array_uprobe()?

> +
> +		bpf_prog_put_recursion_context(prog);
> +		item++;
> +	}
> +	bpf_reset_run_ctx(old_run_ctx);
> +	migrate_enable();
> +	return ret;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422-sleepable_tracepoints-v12-0-744bf0e3b311@meta.com?part=2

  parent reply	other threads:[~2026-04-22 22:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22 15:27 [PATCH bpf-next v12 0/6] bpf: Add support for sleepable tracepoint programs Mykyta Yatsenko
2026-04-22 15:27 ` [PATCH bpf-next v12 1/6] bpf: Add sleepable support for raw " Mykyta Yatsenko
2026-04-22 21:43   ` sashiko-bot
2026-04-22 15:27 ` [PATCH bpf-next v12 2/6] bpf: Add bpf_prog_run_array_sleepable() Mykyta Yatsenko
2026-04-22 16:06   ` bot+bpf-ci
2026-04-22 16:36     ` Mykyta Yatsenko
2026-04-22 17:00       ` Alexei Starovoitov
2026-04-22 17:57         ` Kumar Kartikeya Dwivedi
2026-04-22 18:02           ` Kumar Kartikeya Dwivedi
2026-04-22 18:27             ` Mykyta Yatsenko
2026-04-22 22:02   ` sashiko-bot [this message]
2026-04-22 15:27 ` [PATCH bpf-next v12 3/6] bpf: Add sleepable support for classic tracepoint programs Mykyta Yatsenko
2026-04-22 23:06   ` sashiko-bot
2026-04-22 15:27 ` [PATCH bpf-next v12 4/6] bpf: Verifier support for sleepable " Mykyta Yatsenko
2026-04-22 15:27 ` [PATCH bpf-next v12 5/6] libbpf: Add section handlers for sleepable tracepoints Mykyta Yatsenko
2026-04-22 15:27 ` [PATCH bpf-next v12 6/6] selftests/bpf: Add tests for sleepable tracepoint programs Mykyta Yatsenko

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=20260422220231.A8141C19425@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=mykyta.yatsenko5@gmail.com \
    --cc=sashiko@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