From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Emil Tsalapatis <emil@etsalapatis.com>,
kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v1 04/14] bpf: Drop dead spill diagnostic condition
Date: Sat, 15 Aug 2026 23:39:46 -0700 [thread overview]
Message-ID: <5e67f44f28df257f67350ec95e2a9cbd77864da9.camel@gmail.com> (raw)
In-Reply-To: <20260816015746.2632990-5-memxor@gmail.com>
On Sun, 2026-08-16 at 03:57 +0200, Kumar Kartikeya Dwivedi wrote:
> diag_record_mod() appears to allow identical spill events to be suppressed,
> but diag_mod_keeps_lineage() only accepts register write events. The spill
> producer also supplies a stack target and an explicit origin, so a spill can
> never satisfy this conjunction.
>
> Restrict the condition to writes to reflect the filter's actual contract and
> avoid suggesting that it applies to spills.
>
> Link: https://lore.kernel.org/bpf/48e6f021b89562f68850fe21ef8c78719819b04cf9c4e4f50bc791937d37ace8@mail.kernel.org/
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
> kernel/bpf/diagnostics.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/diagnostics.c b/kernel/bpf/diagnostics.c
> index 33b7d9e8e2c3..37ed22a764e0 100644
> --- a/kernel/bpf/diagnostics.c
> +++ b/kernel/bpf/diagnostics.c
> @@ -1531,8 +1531,7 @@ static void diag_record_mod(struct bpf_verifier_env *env, u32 insn_idx,
> } else if (diag_mod_insn_origin(env, insn_idx, &target, &event.mod.origin)) {
> event.mod.origin_valid = true;
> }
> - if (old_reg && new_reg &&
> - (reason == BPF_DIAG_MOD_WRITE || reason == BPF_DIAG_MOD_SPILL) &&
> + if (old_reg && new_reg && reason == BPF_DIAG_MOD_WRITE &&
> !memcmp(&event.mod.old, &event.mod.new, sizeof(event.mod.old)) &&
> !event.mod.origin_valid &&
> diag_mod_keeps_lineage(env, &event))
Q: does this filter ever fires?
The condition appears to be very narrow.
next prev parent reply other threads:[~2026-08-16 6:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 1:57 [PATCH bpf-next v1 00/14] Follow ups for verifier errors set Kumar Kartikeya Dwivedi
2026-08-16 1:57 ` [PATCH bpf-next v1 01/14] bpf: Correct verifier diagnostic attribution for stack reads Kumar Kartikeya Dwivedi
2026-08-16 6:34 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 02/14] selftests/bpf: Test verifier stack-read diagnostic attribution Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
2026-08-16 6:35 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 03/14] bpf: Preserve R0 lineage across helper calls Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 6:12 ` Eduard Zingerman
2026-08-16 6:36 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 04/14] bpf: Drop dead spill diagnostic condition Kumar Kartikeya Dwivedi
2026-08-16 6:39 ` Eduard Zingerman [this message]
2026-08-16 1:57 ` [PATCH bpf-next v1 05/14] bpf: Use canonical stack argument names in diagnostics Kumar Kartikeya Dwivedi
2026-08-16 6:40 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 06/14] bpf: Correct kfunc argument diagnostics Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
2026-08-16 6:50 ` Eduard Zingerman
2026-08-16 6:52 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 07/14] selftests/bpf: Test " Kumar Kartikeya Dwivedi
2026-08-16 6:53 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 08/14] bpf: Report non-sleepable kfunc programs accurately Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 7:32 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 09/14] selftests/bpf: Test non-sleepable kfunc context Kumar Kartikeya Dwivedi
2026-08-16 2:30 ` bot+bpf-ci
2026-08-16 7:37 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 10/14] bpf: Correct Program Structure diagnostic context Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
2026-08-16 7:58 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 11/14] bpf: Preserve source attribution without source text Kumar Kartikeya Dwivedi
2026-08-16 8:01 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 12/14] selftests/bpf: Test Program Structure diagnostic context Kumar Kartikeya Dwivedi
2026-08-16 8:06 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 13/14] bpf: Distinguish function references in policy diagnostics Kumar Kartikeya Dwivedi
2026-08-16 8:09 ` Eduard Zingerman
2026-08-16 1:57 ` [PATCH bpf-next v1 14/14] selftests/bpf: Test pseudo-function " Kumar Kartikeya Dwivedi
2026-08-16 2:45 ` bot+bpf-ci
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=5e67f44f28df257f67350ec95e2a9cbd77864da9.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=memxor@gmail.com \
/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