On Wed, Jan 26, 2022 at 1:48 PM Kui-Feng Lee <kuifeng@xxxxxx> wrote: > > Allow users to attach a 64-bits cookie to a BPF program when link it > to fentry, fexit, or fmod_ret of a function. > > This changeset includes several major changes. > > - Add a new field bpf_cookie to struct raw_tracepoint, so that a user > can attach a cookie to a program. > > - Store flags in trampoline frames to provide the flexibility of > storing more values in these frames. > > - Store the program ID of the current BPF program in the trampoline > frame. > > - The implmentation of bpf_get_attach_cookie() for tracing programs > to read the attached cookie. flags, prog_id, cookie... I don't follow what's going on here. cookie is supposed to be per link. Doing it for fentry only will be inconvenient for users. For existing kprobes there is no good place to store it. iirc. For multi attach kprobes there won't be a good place either. I think cookie should be out of band. Maybe lets try a resizable map[ip]->cookie and don't add 'cookie' arrays to multi-kprobe attach, 'cookie' field to kprobe, fentry, and other attach apis. Adding 'cookie' to all of them is quite a bit of churn for kernel and user space. I think resizable bpf map[u64]->u64 solves this problem. Maybe cookie isn't even needed. If the bpf prog can have a clean map[bpf_get_func_ip()] that doesn't have to be sized up front it will address the need.
