BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: bot+bpf-ci@kernel.org, memxor@gmail.com, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
	emil@etsalapatis.com, 	kkd@meta.com, kernel-team@meta.com,
	martin.lau@kernel.org, yonghong.song@linux.dev, 	clm@meta.com,
	ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v5 10/14] bpf: Report Resource Lifetime reference leaks
Date: Sat, 15 Aug 2026 10:36:15 -0700	[thread overview]
Message-ID: <ea92f8fc6fef805d35a0d770df3b9dcd1931d0ed.camel@gmail.com> (raw)
In-Reply-To: <6c6f4191cbeb46ebbb55441a67f95e48778ad1ae155d493fdb03cc7c3813e84d@mail.kernel.org>

On Sat, 2026-08-15 at 07:34 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/diagnostics.c b/kernel/bpf/diagnostics.c
> > index 058574a1411e..5d20ea9e470e 100644
> > --- a/kernel/bpf/diagnostics.c
> > +++ b/kernel/bpf/diagnostics.c
> 
> [ ... ]
> 
> > @@ -1735,6 +1736,96 @@ void bpf_diag_mem_bounds(struct bpf_verifier_env *env, u32 insn_idx, int regno,
> >  		env, "Add or adjust a bounds check that proves offset + access_size stays within the object.");
> >  }
> > 
> > +static const char *diag_lock_name(const struct bpf_reference_state *lock)
> > +{
> > +	switch (lock->type) {
> > +	case REF_TYPE_LOCK:
> > +		return "bpf_spin_lock";
> > +	case REF_TYPE_RES_LOCK:
> > +		return "resource spin lock";
> > +	case REF_TYPE_RES_LOCK_IRQ:
> > +		return "IRQ-saving resource spin lock";
> > +	default:
> > +		return "lock";
> > +	}
> > +}
> > +
> > +static void diag_res_report(struct bpf_verifier_env *env, u32 insn_idx, const char *problem,
> > +			    const char *reason)
> > +{
> > +	bpf_diag_header(env, RESOURCE_LIFETIME_SAFETY, problem);
> > +	diag_reason(env, "%s", reason);
> > +
> > +	diag_section(env, "At");
> > +	bpf_diag_source(env, insn_idx, "error", "%s", problem);
> > +}
> 
> [ ... ]
> 
> > +void bpf_diag_leak(struct bpf_verifier_env *env, u32 ref_id, u32 alloc_insn, u32 fail_insn)
> > +{
> > +	struct bpf_diag_history_opts opts = {
> > +		.scope = BPF_DIAG_HISTORY_SCOPE_REF,
> > +		.ref_id = ref_id,
> > +	};
> > +
> > +	bpf_diag_header(env, RESOURCE_LIFETIME_SAFETY, "unreleased resource");
> > +	diag_reason(
> > +		env, "Owned resource (id=%u) was acquired at instruction %u and still needs to be released before this exit path.",
> > +		ref_id, alloc_insn);
> > +
> > +	diag_section(env, "At");
> > +	bpf_diag_source(env, fail_insn, "error",
> > +			"owned resource (id=%u) still needs release", ref_id);
> > +
> > +	diag_print_history(env, &opts);
> > +
> > +	diag_suggestion(
> > +		env, "Release or transfer ownership of the acquired resource on every path before the program exits.");
> > +}
> 
> Does the exit-path wording fit all three call sites?  bpf_diag_leak()
> says "still needs to be released before this exit path" and "before
> the program exits", but check_reference_leak() is reached from three
> different code paths via check_resource_leak():
> 
>   process_bpf_exit_full()  <- actual program exit
>   check_helper_call()      <- tail_call rejection
>   check_ld_abs()           <- BPF_LD_[ABS|IND] rejection
> 
> For BPF_LD_[ABS|IND], the reference is not lost at an exit at all.

Bot is confused.

  reply	other threads:[~2026-08-15 17:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15  6:45 [PATCH bpf-next v5 00/14] Redesign Verification Errors Kumar Kartikeya Dwivedi
2026-08-15  6:45 ` [PATCH bpf-next v5 01/14] bpf: Add verifier diagnostics report helpers Kumar Kartikeya Dwivedi
2026-08-15  6:52   ` sashiko-bot
2026-08-15  7:20   ` bot+bpf-ci
2026-08-15  6:45 ` [PATCH bpf-next v5 02/14] bpf: Add source and instruction diagnostic context Kumar Kartikeya Dwivedi
2026-08-15  7:01   ` sashiko-bot
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15  6:45 ` [PATCH bpf-next v5 03/14] bpf: Add verifier diagnostic event log Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15  6:45 ` [PATCH bpf-next v5 04/14] bpf: Prune verifier diagnostics when switching paths Kumar Kartikeya Dwivedi
2026-08-15  6:46 ` [PATCH bpf-next v5 05/14] bpf: Track verifier register diagnostic events Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15  7:38   ` sashiko-bot
2026-08-15  6:46 ` [PATCH bpf-next v5 06/14] bpf: Track verifier reference " Kumar Kartikeya Dwivedi
2026-08-15  6:46 ` [PATCH bpf-next v5 07/14] bpf: Track verifier context " Kumar Kartikeya Dwivedi
2026-08-15  7:20   ` bot+bpf-ci
2026-08-15  6:46 ` [PATCH bpf-next v5 08/14] bpf: Report Register Type Safety errors Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15 17:29     ` Eduard Zingerman
2026-08-15  6:46 ` [PATCH bpf-next v5 09/14] bpf: Report Memory Safety bounds errors Kumar Kartikeya Dwivedi
2026-08-15  6:59   ` sashiko-bot
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15  6:46 ` [PATCH bpf-next v5 10/14] bpf: Report Resource Lifetime reference leaks Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15 17:36     ` Eduard Zingerman [this message]
2026-08-15  6:46 ` [PATCH bpf-next v5 11/14] bpf: Report Call Type Safety argument errors Kumar Kartikeya Dwivedi
2026-08-15  7:49   ` bot+bpf-ci
2026-08-15 18:00     ` Eduard Zingerman
2026-08-15  6:46 ` [PATCH bpf-next v5 12/14] bpf: Report Execution Context Safety errors Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15  6:46 ` [PATCH bpf-next v5 13/14] bpf: Report Program Structure CFG errors Kumar Kartikeya Dwivedi
2026-08-15  7:34   ` bot+bpf-ci
2026-08-15 17:50     ` Eduard Zingerman
2026-08-15  6:46 ` [PATCH bpf-next v5 14/14] bpf: Report Policy helper and kfunc errors Kumar Kartikeya Dwivedi
2026-08-15  7:20   ` bot+bpf-ci
2026-08-15 17:39     ` Eduard Zingerman
2026-08-15 18:57 ` [PATCH bpf-next v5 00/14] Redesign Verification Errors patchwork-bot+netdevbpf

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=ea92f8fc6fef805d35a0d770df3b9dcd1931d0ed.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clm@meta.com \
    --cc=daniel@iogearbox.net \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    --cc=yonghong.song@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