From: bot+bpf-ci@kernel.org
To: hui.zhu@linux.dev, akpm@linux-foundation.org, hannes@cmpxchg.org,
mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, shuah@kernel.org,
peterz@infradead.org, ojeda@kernel.org, nathan@kernel.org,
kees@kernel.org, tj@kernel.org, jeffxu@chromium.org,
mkoutny@suse.com, kernel@jfarr.cc, brauner@kernel.org,
rdunlap@infradead.org, brgerst@gmail.com, masahiroy@kernel.org,
davem@davemloft.net, kuba@kernel.org, hawk@kernel.org,
inwardvessel@gmail.com, willemb@google.com,
kerneljasonxing@gmail.com, paul.chaignon@gmail.com,
a.s.protopopov@gmail.com, ameryhung@gmail.com,
chenridong@huaweicloud.com, lance.yang@linux.dev,
jiayuan.chen@linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, cgroups@vger.kernel.org, bpf@vger.kernel.org,
netdev@vger.kernel.org, linu@kvack.org,
x-kselftest@vger.kernel.org
Cc: ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,clm@meta.com,ihor.solodrai@linux.dev
Subject: Re: [RFC PATCH bpf-next v5 05/12] libbpf: introduce bpf_map__attach_struct_ops_opts()
Date: Tue, 27 Jan 2026 10:08:31 +0000 (UTC) [thread overview]
Message-ID: <7a66cf5f0e6a1e441fde4e593b26326132bd100531a9a1c5d318edf526ad6a6c@mail.kernel.org> (raw)
In-Reply-To: <635923ceadf1899672e4f7727ddc52554c11a3ac.1769506741.git.zhuhui@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 5846de364209..84a53c594f48 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -884,6 +884,14 @@ int bpf_link_create(int prog_fd, int target_fd,
> if (!OPTS_ZEROED(opts, cgroup))
> return libbpf_err(-EINVAL);
> break;
> + case BPF_STRUCT_OPS:
> + relative_fd = OPTS_GET(opts, cgroup.relative_fd, 0);
> + attr.link_create.cgroup.relative_fd = relative_fd;
> + attr.link_create.cgroup.expected_revision =
> + OPTS_GET(opts, cgroup.expected_revision, 0);
The bpf_link_create() BPF_STRUCT_OPS case reads expected_revision from
the opts, but looking at bpf_map__attach_struct_ops_opts() below...
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 0c8bf0b5cce4..70a00da54ff5 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
[ ... ]
> @@ -13503,7 +13510,9 @@ struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map)
> return &link->link;
> }
>
> - fd = bpf_link_create(map->fd, 0, BPF_STRUCT_OPS, NULL);
> + link_opts.cgroup.relative_fd = OPTS_GET(opts, relative_fd, 0);
> +
> + fd = bpf_link_create(map->fd, 0, BPF_STRUCT_OPS, &link_opts);
Should there also be a line here to forward expected_revision? The
bpf_struct_ops_opts struct defines expected_revision and the BPF_STRUCT_OPS
case in bpf_link_create() reads it, but this function only sets relative_fd.
If a user passes expected_revision in their opts, it appears to be silently
ignored.
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index dfc37a615578..5aef44bcfcc2 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
[ ... ]
> +struct bpf_struct_ops_opts {
> + /* size of this struct, for forward/backward compatibility */
> + size_t sz;
> + __u32 flags;
> + __u32 relative_fd;
> + __u64 expected_revision;
^^^^^^^^^^^^^^^^
> + size_t :0;
> +};
> +#define bpf_struct_ops_opts__last_field expected_revision
The expected_revision field is declared here and is even the __last_field,
but it does not appear to be forwarded to bpf_link_create_opts in
bpf_map__attach_struct_ops_opts(). Is this intentional, or was the
forwarding line missed?
---
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/21392729810
AI-authorship-score: low
AI-authorship-explanation: Commit message and code follow standard kernel/libbpf conventions without unusual patterns typically associated with AI-generated content.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: The expected_revision field in bpf_struct_ops_opts is defined but silently ignored, which could cause unexpected behavior for users relying on revision checking, but does not cause crashes or security issues.
next prev parent reply other threads:[~2026-01-27 10:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 9:42 [RFC PATCH bpf-next v5 00/12] mm: memcontrol: Add BPF hooks for memory controller Hui Zhu
2026-01-27 9:42 ` [RFC PATCH bpf-next v5 01/12] bpf: move bpf_struct_ops_link into bpf.h Hui Zhu
2026-01-27 9:42 ` [RFC PATCH bpf-next v5 02/12] bpf: initial support for attaching struct ops to cgroups Hui Zhu
2026-01-27 9:42 ` [RFC PATCH bpf-next v5 03/12] bpf: mark struct oom_control's memcg field as TRUSTED_OR_NULL Hui Zhu
2026-01-27 9:42 ` [RFC PATCH bpf-next v5 04/12] mm: define mem_cgroup_get_from_ino() outside of CONFIG_SHRINKER_DEBUG Hui Zhu
2026-01-27 9:42 ` [RFC PATCH bpf-next v5 05/12] libbpf: introduce bpf_map__attach_struct_ops_opts() Hui Zhu
2026-01-27 10:08 ` bot+bpf-ci [this message]
2026-01-27 9:45 ` [RFC PATCH bpf-next v5 06/12] bpf: Pass flags in bpf_link_create for struct_ops Hui Zhu
2026-01-27 9:45 ` [RFC PATCH bpf-next v5 07/12] libbpf: Support passing user-defined flags " Hui Zhu
2026-01-27 9:45 ` [RFC PATCH bpf-next v5 08/12] mm: memcontrol: Add BPF struct_ops for memory controller Hui Zhu
2026-01-27 10:08 ` bot+bpf-ci
2026-01-27 9:47 ` [RFC PATCH bpf-next v5 09/12] selftests/bpf: Add tests for memcg_bpf_ops Hui Zhu
2026-01-27 10:08 ` bot+bpf-ci
2026-01-27 9:47 ` [RFC PATCH bpf-next v5 10/12] mm/bpf: Add BPF_F_ALLOW_OVERRIDE support " Hui Zhu
2026-01-27 10:08 ` bot+bpf-ci
2026-01-27 9:47 ` [RFC PATCH bpf-next v5 11/12] selftests/bpf: Add test for memcg_bpf_ops hierarchies Hui Zhu
2026-01-27 9:48 ` [RFC PATCH bpf-next v5 12/12] samples/bpf: Add memcg priority control example Hui Zhu
2026-01-27 10:08 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a66cf5f0e6a1e441fde4e593b26326132bd100531a9a1c5d318edf526ad6a6c@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=a.s.protopopov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=brgerst@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=hui.zhu@linux.dev \
--cc=ihor.solodrai@linux.dev \
--cc=inwardvessel@gmail.com \
--cc=jeffxu@chromium.org \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kerneljasonxing@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linu@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=masahiroy@kernel.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=sdf@fomichev.me \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=willemb@google.com \
--cc=x-kselftest@vger.kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox