Re: [RFC PATCH bpf-next v6 12/12] samples/bpf: Add memcg priority control example
From: bot+bpf-ci@kernel.org
Date: 2026-02-04 09:28:37
Also in:
bpf, cgroups, linux-kselftest, linux-mm, lkml
1. memcg.bpf.c: A BPF program that monitors PGFAULT events on a high-priority cgroup. When activity exceeds a threshold, it uses the `get_high_delay_ms`, `below_low`, or `below_min` hooks to apply pressure on a low-priority cgroup.
Is this description accurate? Looking at the code, below_low and
below_min are implemented in high_mcg_ops which is attached to the
high-priority cgroup:
high_mcg_ops = {
.below_low = (void *)below_low_impl,
.below_min = (void *)below_min_impl,
};
And in memcg.c, high_mcg_ops is attached via:
.relative_fd = high_cgroup_fd,
According to the memcg_bpf_ops documentation, below_low and below_min
provide protection for a cgroup (returning true means the cgroup is
protected from reclaim), rather than applying pressure. Only
get_high_delay_ms (attached to the low-priority cgroup via low_mcg_ops)
actually throttles/applies pressure.
Could the commit message clarify that below_low/below_min protect the
high-priority cgroup, while get_high_delay_ms throttles the low-priority
one?
quoted hunk ↗ jump to hunk
diff --git a/samples/bpf/memcg.c b/samples/bpf/memcg.c new file mode 100644 index 000000000..0ed174608 --- /dev/null +++ b/samples/bpf/memcg.c
[ ... ]
+ prog = bpf_object__find_program_by_name(obj,
+ "handle_count_memcg_events");
+ if (!prog) {
+ fprintf(stderr,
+ "ERROR: finding a prog in BPF object file failed\n");
+ goto out;
+ }If bpf_object__find_program_by_name() fails here, should the err variable be set to an error code before the goto? As written, err could be 0 (from the previous successful bpf_map_update_elem() call), causing main() to return 0 (success) even though the program failed. --- 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/21665371660 AI-authorship-score: low AI-authorship-explanation: The technical misunderstanding about hook purposes and dual authorship suggest human collaboration rather than AI generation. issues-found: 2 issue-severity-score: low issue-severity-explanation: The issues found are a misleading commit message description and a missing error code assignment in sample code, neither of which causes system instability.