Re: [PATCH v2 3/3] bpf: cgroup: restore sysctl new-value replacement

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Inaccurate commit message and 'Fixes' tag attribution, which will cause regressions in stable backports.
--

commit 7f62fca2fcdc45d11be946984a6167b4460d8a59
Author: Dawei Feng <dawei.feng@seu.edu.cn>

bpf: cgroup: restore sysctl new-value replacement

This commit updates the return value check in __cgroup_bpf_run_filter_sysctl
to check for 0 instead of 1. It intends to fix an issue where the modified
sysctl value was ignored because the runner macro returns 0 on success.

> Commit 4e63acdff864 ("bpf: Introduce bpf_sysctl_{get,set}_new_value
> helpers") changed the success return value to 0, but failed to update the
> corresponding check in __cgroup_bpf_run_filter_sysctl().

[Severity: High]
Is this attribution accurate? Commit 4e63acdff864 introduced the sysctl hook
with the ret == 1 check, which was correct at the time because the legacy
BPF_PROG_RUN_ARRAY returned 1 on success.

It appears the return value was actually changed later by commit
f10d05966196 (bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow
boolean), which changed the macro to return 0 on success but missed
updating this condition.

> Fixes: 4e63acdff864 ("bpf: Introduce bpf_sysctl_{get,set}_new_value helpers")
> Cc: stable@vger.kernel.org

[Severity: High]
Since this patch targets 4e63acdff864 for stable backports, could this cause
a regression if applied to older LTS kernels (like 5.4, 5.10, or 5.15)?

On those older kernels where f10d05966196 is not present, the runner still
returns 1 on success. Applying this fix would change the condition to !ret,
which evaluates to false on success and actively breaks the sysctl override
functionality.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529031026.2716641-1-dawei.feng@seu.edu.cn?part=3