On Tue, 3 Mar 2026 at 17:04, [off-list ref] wrote:

quoted

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c

[ ... ]

quoted

+     switch (match) {
+     case BPF_MAP_OWNER_MATCH_FOR_INIT:
+             if (owner->kprobe_write_ctx != aux->kprobe_write_ctx)
+                     return false;
+             break;
+
+     case BPF_MAP_OWNER_MATCH_FOR_UPDATE:
+             if (!owner->kprobe_write_ctx && aux->kprobe_write_ctx)
+                     return false;
+             break;
+     }

In the v1 review, Alexei Starovoitov asked for strict conformance
both ways rather than one-directional validation:

    "Don't be fancy. Require strict conformance both ways
    in *all* patches."

https://lore.kernel.org/bpf/CAADnVQ+-V0-1i8_+CYpK7G0CnV-2n8e9Szv43yM3Az197eL_0A@mail.gmail.com/ (local)

The BPF_MAP_OWNER_MATCH_FOR_UPDATE case still uses one-directional
matching, rejecting only !owner->kprobe_write_ctx && aux->kprobe_write_ctx
but allowing the reverse.  Was this an intentional design choice, and
if so, should the changelog note the disagreement?

Let's follow the approach Alexei outlined, while the changes look ok
to me, let's remove the one way check and just do
owner->kprobe_write_ctx != aux->kprobe_write_ctx, same for the other
two checks. With this we can also get rid of this INIT vs UPDATE
distinction.

Other than that I think patches are good, please also test both
directions in the selftest in next respin.

---
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/22630000544