On Sun, Dec 10, 2023 at 7:30 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > 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. Every extra pair of eyes is worth it :) Not finding anything obviously broken is still a good result, thanks! > > [...]
