All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 19/29] bpf: Allow a callee to release its caller's resources
Date: Wed, 11 Nov 2026 17:02:51 +0000	[thread overview]
Message-ID: <sashiko-outbox-209363@kernel.org> (raw)
In-Reply-To: <94c4fd13b4c95090e159b905110781973e8e56ad.1794399387.git.memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] bpf: missing releases_inherited mark in release_context_state()
--

commit e5be88d9a8d47ae92f3e9f98a812d289864c60bf
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Allow a callee to release its caller's resources

This commit allows a subprogram in a program that throws to release
resources acquired by its caller, clearing the caller's hidden slot before
the call when needed and marking intermediate subprograms with
releases_inherited at the release site so they are verified in the context
of their callers.

> diff --git a/kernel/bpf/frame_desc.c b/kernel/bpf/frame_desc.c
> index 9854be9ab4781..d2ad02925f061 100644
> --- a/kernel/bpf/frame_desc.c
> +++ b/kernel/bpf/frame_desc.c

[ ... ]

> @@ -689,12 +690,76 @@ static int rel_add(struct bpf_verifier_env *env, u32 insn, u16 acq, u8 reg, u8 f
>  	return 0;
>  }
>  
> +/*
> + * What the call @insn of a subprog means for what acquisition @acq acquired
> + * is noted in the record of the two, see struct bpf_res_call. NULL when there
> + * is no memory for one.
> + */
> +static struct bpf_res_call *call_note(struct bpf_verifier_env *env, u32 insn, u16 acq)
> +{
> +	u32 i, cnt = env->res_call_cnt;
> +	struct bpf_res_call *c;
> +
> +	for (i = 0; i < cnt; i++)
> +		if (env->res_calls[i].insn == insn && env->res_calls[i].acq == acq)
> +			return &env->res_calls[i];
> +	c = kvrealloc(env->res_calls, array_size(cnt + 1, sizeof(*c)), GFP_KERNEL_ACCOUNT);
> +	if (!c)
> +		return NULL;
> +	c[cnt] = (struct bpf_res_call) { .insn = insn, .acq = acq };
> +	env->res_calls = c;
> +	env->res_call_cnt = cnt + 1;
> +	return &c[cnt];
> +}
> +
> +/*
> + * The current insn releases @ref, which a frame below the current one owns.
> + * Nothing tells a callee where the slot of its caller is, so it cannot clear
> + * one. There are two ways out:
> + *
> + *  - What the caller holds without a slot needs none cleared: its sites say
> + *    where the handle is on the visits that find it held, and say nothing on
> + *    those that find it released.
> + *  - The caller clears its slot in front of the call when the callee releases
> + *    the resource on every path and no throw finds the caller holding it at
> + *    the call, see bpf_frame_desc_resolve().
> + *
> + * The functions between the owner and the current frame are verified in the
> + * context of their callers from now on, so that every throw sees the frames
> + * below it as they are. The round of the main pass that finds one out is done
> + * again, since it recorded the frames of its callers at the call, holding
> + * what they held then.
> + */
> +static int foreign_release(struct bpf_verifier_env *env, const struct bpf_verifier_state *st,
> +			   const struct bpf_reference_state *ref, struct bpf_res_acq *acq)
> +{
> +	const struct bpf_func_state *below = st->frame[ref->frameno + 1];
> +	struct bpf_subprog_info *sub;
> +	struct bpf_res_call *c;
> +	int f;
> +
> +	for (f = ref->frameno + 1; f <= st->curframe; f++) {
> +		sub = &env->subprog_info[st->frame[f]->subprogno];
> +		if (sub->releases_inherited)
> +			continue;
> +		sub->releases_inherited = true;
> +		env->frame_desc_redo = true;
> +	}

[Severity: High]
Does release_context_state() also need to set sub->releases_inherited and
env->frame_desc_redo when a frame leaves an inherited RCU read or
preemption-disabled section?

foreign_release() marks sub->releases_inherited when a callee releases an
entry in st->refs[] so that a subprog that throws without returning is
verified in the context of its caller.  However, RCU and preemption-disabled
sections are tracked via entry_rcu_locks and entry_preempt_locks rather
than st->refs[]:

kernel/bpf/verifier.c:release_context_state() {
	for (fr = 0; fr <= state->curframe; fr++) {
		frame = state->frame[fr];
		if (frame->entry_rcu_locks > state->active_rcu_locks)
			frame->rcu_released_below += frame->entry_rcu_locks - state->active_rcu_locks;
		if (frame->entry_preempt_locks > state->active_preempt_locks)
			frame->preempt_released_below += frame->entry_preempt_locks -
							 state->active_preempt_locks;
    ...
}

For those sections, releases_inherited is only set in bpf_flow_return() when
the callee returns.  If a static subprogram calls bpf_rcu_read_unlock() on
its caller's RCU section and then calls bpf_throw() without returning, it
remains verified on its own without the caller's frames in env->cur_state.
When bpf_rcu_read_unlock() calls invalidate_rcu_protected_refs(), it does
not see STACK_ITER slots with MEM_RCU on the caller's stack, allowing an
RCU-protected iterator to outlive its RCU section across a sleepable call
before bpf_throw() unwinds the stack and invokes the iterator destructor
(use-after-free).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1794399387.git.memxor@gmail.com?part=19

  reply	other threads:[~2026-11-11 17:02 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 12:56 [PATCH bpf-next v1 00/29] Exceptions - Resource Cleanup - Redux Kumar Kartikeya Dwivedi
2026-11-11 12:56 ` [PATCH bpf-next v1 01/29] bpf: Record where JITs save callee-saved registers Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 02/29] bpf: Add bpf_throw_unwind() and an arch entry hook Kumar Kartikeya Dwivedi
2026-11-11 14:45   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 03/29] bpf, x86: Capture registers in a native bpf_throw() entry Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 04/29] bpf, arm64: " Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 05/29] bpf: Restore callee-saved registers from unwound frames Kumar Kartikeya Dwivedi
2026-11-11 14:41   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 06/29] bpf: Keep last insn's aux data in add_hidden_subprog() Kumar Kartikeya Dwivedi
2026-11-11 14:38   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 07/29] bpf: Add one allocator for hidden stack slots Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 15:15   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 08/29] bpf: Add flags and release kfuncs to the dtor registry Kumar Kartikeya Dwivedi
2026-11-11 13:33   ` bot+bpf-ci
2026-11-11 15:36   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 09/29] bpf: Register cleanup destructors for more types Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 15:00   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 10/29] bpf: Record where JITed frames keep the BPF stack Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 11/29] bpf: Give every reference an owner frame Kumar Kartikeya Dwivedi
2026-11-11 13:33   ` bot+bpf-ci
2026-11-11 12:57 ` [PATCH bpf-next v1 12/29] bpf: Release resources in hidden slots on bpf_throw() Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 15:30   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 13/29] bpf: Track held resources in hidden stack slots Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 16:12   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 14/29] bpf: Describe held resources at throw sites Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 12:57 ` [PATCH bpf-next v1 15/29] bpf: Describe handles in registers " Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 16:11   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 16/29] bpf: Describe locks " Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 16:04   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 17/29] bpf: Apply hidden slot limits only when a slot is needed Kumar Kartikeya Dwivedi
2026-11-11 16:31   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 18/29] bpf: Allow a callee to leave resources with its caller Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 16:41   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 19/29] bpf: Allow a callee to release its caller's resources Kumar Kartikeya Dwivedi
2026-11-11 17:02   ` sashiko-bot [this message]
2026-11-11 12:57 ` [PATCH bpf-next v1 20/29] bpf: Transfer a reference to the callee that releases it Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 16:57   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 21/29] bpf: Support callx when a callee releases resources Kumar Kartikeya Dwivedi
2026-11-11 14:04   ` bot+bpf-ci
2026-11-11 17:13   ` sashiko-bot
2026-11-11 12:57 ` [PATCH bpf-next v1 22/29] selftests/bpf: Test rejected throws that hold resources Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 23/29] selftests/bpf: Test resource cleanup on bpf_throw() Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 24/29] selftests/bpf: Test cleanup of handles on the stack Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 25/29] selftests/bpf: Test cleanup of handles in registers Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 26/29] selftests/bpf: Test callees releasing caller resources Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 27/29] selftests/bpf: Test resources a callee leaves with its caller Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 28/29] selftests/bpf: Test cleanup of locks described at sites Kumar Kartikeya Dwivedi
2026-11-11 12:57 ` [PATCH bpf-next v1 29/29] selftests/bpf: Test callee releases through callx Kumar Kartikeya Dwivedi
2026-11-11 20:33 ` [PATCH bpf-next v1 00/29] Exceptions - Resource Cleanup - Redux Alexei Starovoitov

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-209363@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.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 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.