[PATCH bpf-next 0/8] BPF token support in libbpf's BPF object

[Eduard Zingerman]

On Thu, 2023-12-07 at 10:54 -0800, Andrii Nakryiko wrote:
> Add fuller support for BPF token in high-level BPF object APIs. This is the
> most frequently used way to work with BPF using libbpf, so supporting BPF
> token there is critical.
> 
> Patch #1 is improving kernel-side BPF_TOKEN_CREATE behavior by rejecting to
> create "empty" BPF token with no delegation. This seems like saner behavior
> which also makes libbpf's caching better overall. If we ever want to create
> BPF token with no delegate_xxx options set on BPF FS, we can use a new flag to
> enable that.
> 
> Patches #2-#5 refactor libbpf internals, mostly feature detection code, to
> prepare it from BPF token FD.
> 
> Patch #6 adds options to pass BPF token into BPF object open options. It also
> adds implicit BPF token creation logic to BPF object load step, even without
> any explicit involvement of the user. If the environment is setup properly,
> BPF token will be created transparently and used implicitly. This allows for
> all existing application to gain BPF token support by just linking with
> latest version of libbpf library. No source code modifications are required.
> All that under assumption that privileged container management agent properly
> set up default BPF FS instance at /sys/bpf/fs to allow BPF token creation.
> 
> Patches #7-#8 adds more selftests, validating BPF object APIs work as expected
> under unprivileged user namespaced conditions in the presence of BPF token.

fwiw, I've read through this patch-set and have not noticed any issues,
all seems good to me. Not sure if that worth much as I'm not terribly
familiar with code base yet.

[...]