netdev - Re: [PATCH v2 bpf-next 2/4] bpf: Support associating BPF program with struct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMB2axMitKK6yvSKkyApMaoD2+W973N+7X2sDKj1yCVAMvakmw@mail.gmail.com>
Date: Fri, 17 Oct 2025 09:49:01 -0700
From: Amery Hung <ameryhung@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: netdev@...r.kernel.org, alexei.starovoitov@...il.com, andrii@...nel.org, 
	daniel@...earbox.net, tj@...nel.org, martin.lau@...nel.org, 
	kernel-team@...a.com, bpf@...r.kernel.org
Subject: Re: [PATCH v2 bpf-next 2/4] bpf: Support associating BPF program with struct_ops

On Fri, Oct 17, 2025 at 9:38 AM Amery Hung <ameryhung@...il.com> wrote:
>
> On Thu, Oct 16, 2025 at 5:19 PM Martin KaFai Lau <martin.lau@...ux.dev> wrote:
> >
> >
> >
> > On 10/16/25 1:45 PM, Amery Hung wrote:
> > > Each associated programs except struct_ops programs of the map will take
> > > a refcount on the map to pin it so that prog->aux->st_ops_assoc, if set,
> > > is always valid. However, it is not guaranteed whether the map members
> > > are fully updated nor is it attached or not. For example, a BPF program
> > > can be associated with a struct_ops map before map_update. The
> >
> > Forgot to ask this, should it at least ensure the map is fully updated
> > or it does not help in the use case?
>
> It makes sense and is necessary. Originally, I thought we don't need
> to make any promise about the state of the map since the struct_ops
> implementers have to track the state of the struct_ops themselves
> anyways. However, checking the state stored in kdata that may be
> incomplete does not look right.
>
> I will only return kdata from bpf_prog_get_assoc_struct_ops () when
> kvalue->common.state == READY or INUSE.

should be kvalue->common.state != INIT to make it consistent across
legacy and link-based attachment.

>
> If tracking the state in struct_ops kdata is overly complicated for
> struct_ops implementers, then we might need to consider changing the
> associated struct_ops from map to link.
>
> >
> > > struct_ops implementer will be responsible for maintaining and checking
> > > the state of the associated struct_ops map before accessing it.
> >