All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
	eddyz87@gmail.com, kernel-team@fb.com, martin.lau@kernel.org,
	mason@kernel.org, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v2 10/20] bpf: Dispatch exception cleanup pads from bpf_throw()
Date: Sat, 19 Sep 2026 12:54:48 -0700	[thread overview]
Message-ID: <09acae72-dfdc-4715-83ba-c6dd2849dba9@linux.dev> (raw)
In-Reply-To: <eb5c029a500542566d71ececa22da94f0e301c49c95880bfec3fcc5f46c36ea4@mail.kernel.org>



On 9/17/26 10:58 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/exception.c b/kernel/bpf/exception.c
>> index b2bf831242b85..521086d084a35 100644
>> --- a/kernel/bpf/exception.c
>> +++ b/kernel/bpf/exception.c
> [ ... ]
>
>> +static int cmp_u32(const void *a, const void *b)
>> +{
>> +	u32 x = *(const u32 *)a, y = *(const u32 *)b;
>> +
>> +	return x < y ? -1 : x > y;
>> +}
> [ ... ]
>
>> +/* Is @idx in the sorted array @at of @n instruction indices? */
>> +static bool insn_idx_in(const u32 *at, u32 n, u32 idx)
>> +{
>> +	u32 l = 0, r = n;
>> +
>> +	while (l < r) {
>> +		u32 m = l + (r - l) / 2;
>> +
>> +		if (idx < at[m])
>> +			r = m;
>> +		else if (idx > at[m])
>> +			l = m + 1;
>> +		else
>> +			return true;
>> +	}
>> +	return false;
>> +}
> This isn't a bug, but could insn_idx_in() just use bsearch() from
> <linux/bsearch.h>, reusing the cmp_u32() already defined above for the
> sort()? kernel/bpf/fixups.c in this series uses bsearch() for similar
> lookups.

Good point. will do.

>
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index f120ae66dbbcb..134aafa6a6c9b 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
> [ ... ]
>
>> @@ -1113,6 +1120,116 @@ static void bpf_restore_subprog_starts(struct bpf_verifier_env *env, u32 *orig_s
>>   	env->subprog_info[env->subprog_cnt].start = env->prog->len;
>>   }
>>
>> +static int cleanup_info_for_subprog(struct bpf_verifier_env *env, struct bpf_prog *sub,
>> +				    u32 start, u32 end)
>> +{
>> +	struct bpf_cleanup_info *recs;
>> +	u32 i, cnt = 0;
>> +	int err;
>> +
>> +	if (!env->cleanup_info_cnt)
>> +		return 0;
>> +
>> +	err = bpf_cleanup_alloc_info(sub->aux);
>> +	if (err)
>> +		return err;
>> +
>> +	err = cleanup_throw_sites_for_subprog(env, sub, start, end);
>> +	if (err)
>> +		return err;
>> +
>> +	err = cleanup_pad_body_for_subprog(env, sub, start, end);
>> +	if (err)
>> +		return err;
>> +
>> +	for (i = start; i < end; i++)
>> +		if (env->insn_aux_data[i].cleanup_pad)
>> +			cnt++;
>> +	if (!cnt)
>> +		return 0;
>> +
>> +	recs = kvmalloc_array(cnt, sizeof(*recs), GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
>> +	if (!recs)
>> +		return -ENOMEM;
>> +
>> +	for (i = start, cnt = 0; i < end; i++) {
>> +		u32 pad = env->insn_aux_data[i].cleanup_pad;
>> +
>> +		if (!pad)
>> +			continue;
>> +		pad--;
>> +		if (verifier_bug_if(pad < start || pad >= end, env,
>> +				    "insn %u is covered by a landing pad at %u outside its subprog [%u, %u)",
>> +				    i, pad, start, end)) {
>> +			kvfree(recs);
>> +			return -EFAULT;
>> +		}
>> +		recs[cnt].begin_off = i - start;
>> +		recs[cnt].end_off = i - start + 1;
>> +		recs[cnt].landing_pad_off = pad - start;
>> +		cnt++;
>> +	}
>> +	return bpf_cleanup_attach_info(sub->aux, recs, cnt);
>> +}
> [ ... ]
>
>>   static int jit_subprogs(struct bpf_verifier_env *env)
>>   {
>>   	struct bpf_prog *prog = env->prog, **func, *tmp;
> [ ... ]
>
>> @@ -1250,6 +1367,10 @@ static int jit_subprogs(struct bpf_verifier_env *env)
>>   		func[i]->aux->token = prog->aux->token;
>>   		if (!i)
>>   			func[i]->aux->exception_boundary = env->seen_exception;
>> +		err = cleanup_info_for_subprog(env, func[i], subprog_start,
>> +					       env->subprog_info[i + 1].start);
> This isn't a bug, but would passing subprog_end (already computed a few
> lines above from env->subprog_info[i + 1].start) be clearer here? It
> keeps the cleanup table's end bound explicitly tied to the same value
> jit_subprogs() uses for func[i]->len.

Good point. subprog_end is a good choice.

>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35308528711


  reply	other threads:[~2026-09-19 19:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  4:41 [PATCH bpf-next v2 00/20] bpf: Run exception cleanup landing pads when bpf_throw() unwinds Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 01/20] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 02/20] bpf: Add the bpf_unwind_resume() kfunc Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 03/20] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19  4:55     ` Alexei Starovoitov
2026-09-19 17:42       ` Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 04/20] bpf: Mark the call sites an exception cleanup table covers Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 05/20] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-18  4:59   ` sashiko-bot
2026-09-19 19:17     ` Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 19:32     ` Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 06/20] bpf: Explore the landing pads no call site reaches Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 19:32     ` Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 08/20] bpf: Walk the exception unwind in the verifier Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 09/20] bpf: Refuse a private stack for a program with an exception cleanup table Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 19:37     ` Yonghong Song
2026-09-18  4:42 ` [PATCH bpf-next v2 10/20] bpf: Dispatch exception cleanup pads from bpf_throw() Yonghong Song
2026-09-18  5:58   ` bot+bpf-ci
2026-09-19 19:54     ` Yonghong Song [this message]
2026-09-18  4:42 ` [PATCH bpf-next v2 11/20] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-18  5:03   ` sashiko-bot
2026-09-19 20:00     ` Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 20:04     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 12/20] bpf, arm64: " Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 20:07     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 13/20] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 14/20] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-18  4:57   ` sashiko-bot
2026-09-19 20:18     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 15/20] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-18  5:00   ` sashiko-bot
2026-09-19 20:21     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 16/20] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-18  5:02   ` sashiko-bot
2026-09-19 20:27     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 17/20] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-18  5:01   ` sashiko-bot
2026-09-19 20:31     ` Yonghong Song
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 20:32     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 18/20] selftests/bpf: Add an end-to-end .bpf_cleanup exception test Yonghong Song
2026-09-18  4:59   ` sashiko-bot
2026-09-18  5:58   ` bot+bpf-ci
2026-09-19 20:34     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 19/20] selftests/bpf: Cover the exception cleanup shapes the chain does not reach Yonghong Song
2026-09-18  5:01   ` sashiko-bot
2026-09-18  5:44   ` bot+bpf-ci
2026-09-19 21:13     ` Yonghong Song
2026-09-18  4:43 ` [PATCH bpf-next v2 20/20] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song

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=09acae72-dfdc-4715-83ba-c6dd2849dba9@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@kernel.org \
    --cc=mason@kernel.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.