All of lore.kernel.org
 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 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.