> 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?

> 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.