> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
[ ... ]
> +enum bpf_map_owner_match_type {
> + BPF_MAP_OWNER_MATCH_FOR_INIT,
> + BPF_MAP_OWNER_MATCH_FOR_UPDATE,
> +};
> +
> static bool bpf_map_owner_matches(const struct bpf_map *map, const struct
> bpf_prog *fp,
> - enum bpf_prog_type prog_type)
> + enum bpf_prog_type prog_type,
> + enum bpf_map_owner_match_type match)
> {
[ ... ]
> + 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...@mail.gmail.com/
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. The v2 changelog lists other Alexei comments
as addressed but does not mention this one.
Was this an intentional design choice, and if so, should the changelog
note the disagreement?
---
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/22582690876
AI-authorship-score: medium
AI-authorship-explanation: Confirmed LLM involvement in v1 development process
(selftests called out by reviewer), but core code changes and v2 revisions
appear human-authored with genuine design engagement.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Unaddressed maintainer review comment requesting
symmetric matching in the UPDATE path; not a code bug or security concern.
