On Wed, Jan 26, 2022 at 09:17:07PM -0800, Alexei Starovoitov wrote: > 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. so you mean passing such map fd to link and have bpf_get_attach_cookie using that map to get the cookie? that could be generic way for all the links I have the 'cookie arrays to multi-kprobe attach' code ready and I think it should be faster than map[ip] hash lookup? I'll need to check jirka > 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. >
