From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BDD6A3911AD; Tue, 26 May 2026 03:06:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779764781; cv=none; b=tAsDI5lLrtZ9sxgI3GkCIxiSIkTOvQcpEbuZcA2SD9S+lZ0IUtb0YIYW+PYDBQg/f9xcySRyzcytgFOYYqJfnaHfjHaKvzQjcayXgf5DKaIa/Uu1eVved/lDK4C/1TX1dCa9sDXNXoDpmqE7nNhm1d6hSWvfM/eJPCwWI7Vi0QA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779764781; c=relaxed/simple; bh=FcRDw5Lbl0rZsMa2D63vn2uDZkbv4VZcgb8y5LuG+pU=; h=Content-Type:MIME-Version:Message-Id:In-Reply-To:References: Subject:From:To:Cc:Date; b=X0EbEQ9gNdqTy8J79tOHvfWRjK+AU8vthY2FF/1wHWnQNfFIl0488ELVuRNZOGOYT+qJnSBu0kWkOHaUKFDhRpUHs9PpK72nVtM5Qmhoj8Bdv7ZOcJAB5UuR7F+3/Z4qguznITAVNavNggnwr6Cmd34LimdGnFtzxzAZLkpQpkI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=fail (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UBVtV9mq reason="signature verification failed"; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UBVtV9mq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 839C51F00A3A; Tue, 26 May 2026 03:06:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779764780; bh=6yTA3niwkhttvCkwwpXJUgDLki0X86ZyRPiud/VTWNI=; h=In-Reply-To:References:Subject:From:To:Cc:Date; b=UBVtV9mqmKcdwQzwwqF60MD2gRVk6VsAOk+ODNyT1Sst9Pl9FMmb9pqCzet6QsHv3 YVTQtJd6/2BIVPeFPTxag3XABXwuNXm4C6BEXWWmDhVc84UJqMi+zQF0RjsREuhabc DP2z1c6bOiGGw/vNo2hZWgJ3L3Dwx6BXyDqBeh7ysTtoGt0gb+naI/5816NE0w1DDz fSgH9tDiPzryEtkPk7Xw9el2r+BpIAr0ZPjeQBw8U4R9ftQsFx9zo1y6lHi451jajZ 2mTKHXhwXQ11+xhINqJ8CmNYXLWcL78T9GrQgY6G9Z7ebElVAw6lBjNYvt2pmY4aL+ RnmkXY3JdCY1A== Content-Type: multipart/mixed; boundary="===============8971296676859346984==" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <89f1d1be0767b0146b61fdc7faad181e447ca7d669f467fb99d8c5a174430101@mail.kernel.org> In-Reply-To: <20bdaa33cc19364f5f10208c79ef94fe43bd5ac1.1779760876.git.zhuhui@kylinos.cn> References: <20bdaa33cc19364f5f10208c79ef94fe43bd5ac1.1779760876.git.zhuhui@kylinos.cn> Subject: Re: [RFC PATCH bpf-next v7 04/11] libbpf: introduce bpf_map__attach_struct_ops_opts() From: bot+bpf-ci@kernel.org To: hui.zhu@linux.dev,ast@kernel.org,daniel@iogearbox.net,john.fastabend@gmail.com,andrii@kernel.org,martin.lau@linux.dev,eddyz87@gmail.com,memxor@gmail.com,song@kernel.org,yonghong.song@linux.dev,jolsa@kernel.org,hannes@cmpxchg.org,mhocko@kernel.org,roman.gushchin@linux.dev,shakeel.butt@linux.dev,muchun.song@linux.dev,inwardvessel@gmail.com,akpm@linux-foundation.org,shuah@kernel.org,davem@davemloft.net,kuba@kernel.org,hawk@kernel.org,sdf@fomichev.me,kpsingh@kernel.org,chen.dylane@linux.dev,yatsenko@meta.com,leon.hwang@linux.dev,a.s.protopopov@gmail.com,ameryhung@gmail.com,tklauser@distanz.ch,eyal.birger@gmail.com,rongtao@cestc.cn,haoluo@google.com,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,willemb@google.com,kerneljasonxing@gmail.com,paul.chaignon@gmail.com,chenridong@huaweicloud.com,lance.yang@linux.dev,jiayu an.chen@linux.dev,linux-kernel@vger.kernel.org,bpf@vger.kernel.org,cgroups@vger.kernel.org,linux-mm@kvack.org,netdev@vger.kernel.org,linux-kselftest@vger.kernel.org Cc: geliang@kernel.org,baohua@kernel.org,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 Date: Tue, 26 May 2026 03:06:19 +0000 (UTC) --===============8971296676859346984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 1e8688975d16..a1b54da1ded2 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c [ ... ] > @@ -13683,11 +13683,18 @@ static int bpf_link__detach_struct_ops(struct bpf_link *link) > return close(link->fd); > } > > -struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map) > +struct bpf_link *bpf_map__attach_struct_ops_opts(const struct bpf_map *map, > + const struct bpf_struct_ops_opts *opts) > { > + DECLARE_LIBBPF_OPTS(bpf_link_create_opts, link_opts); > struct bpf_link_struct_ops *link; > + int err, fd, target_fd; > __u32 zero = 0; > - int err, fd; > + > + if (!OPTS_VALID(opts, bpf_struct_ops_opts)) { > + pr_warn("map '%s': invalid opts\n", map->name); > + return libbpf_err_ptr(-EINVAL); > + } > > if (!bpf_map__is_struct_ops(map)) { > pr_warn("map '%s': can't attach non-struct_ops map\n", map->name); [ ... ] > @@ -13724,7 +13731,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.flags = OPTS_GET(opts, flags, 0); > + target_fd = OPTS_GET(opts, target_fd, 0); > + fd = bpf_link_create(map->fd, target_fd, BPF_STRUCT_OPS, &link_opts); The expected_revision field declared in struct bpf_struct_ops_opts is never read or used. The code only reads flags and target_fd from opts, which could cause silent data loss if users set expected_revision expecting it to be honored. Looking at similar opts structures (bpf_cgroup_opts, bpf_tcx_opts, bpf_netkit_opts), they all pass expected_revision to bpf_link_create_opts. Should expected_revision be propagated here as well? This was raised by bot+bpf-ci@kernel.org in v3: https://lore.kernel.org/bpf/3af5210f45be4a508e584263a5517781ca762d28d4f6b831b987795662715e61@mail.kernel.org/ > if (fd < 0) { > free(link); > return libbpf_err_ptr(fd); [ ... ] > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > index bba4e8464396..18af178547ad 100644 > --- a/tools/lib/bpf/libbpf.h > +++ b/tools/lib/bpf/libbpf.h > @@ -945,6 +945,20 @@ bpf_program__attach_cgroup_opts(const struct bpf_program *prog, int cgroup_fd, > struct bpf_map; > > LIBBPF_API struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map); > + > +struct bpf_struct_ops_opts { > + /* size of this struct, for forward/backward compatibility */ > + size_t sz; > + __u32 flags; > + __u32 target_fd; > + __u64 expected_revision; > + size_t :0; > +}; > +#define bpf_struct_ops_opts__last_field expected_revision > + > +LIBBPF_API struct bpf_link * > +bpf_map__attach_struct_ops_opts(const struct bpf_map *map, > + const struct bpf_struct_ops_opts *opts); > LIBBPF_API int bpf_link__update_map(struct bpf_link *link, const struct bpf_map *map); > > struct bpf_iter_attach_opts { [ ... ] --- 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/26429228214 --===============8971296676859346984==--