On Sun, Mar 20, 2022 at 1:44 AM Kui-Feng Lee <kuifeng@xxxxxx> wrote:
>
> On Fri, 2022-03-18 at 12:21 -0700, Alexei Starovoitov wrote:
> > On Tue, Mar 15, 2022 at 05:42:31PM -0700, Kui-Feng Lee wrote:
> > >
> > > +SEC("fentry/bpf_fentry_test1")
> >
> > Did we discuss whether it makes sense to specify cookie in the SEC()
> > ?
> >
> > Probably no one will be using cookie when prog is attached to a
> > specific
> > function, but with support for poor man regex in SEC the cookie
> > might be useful?
> > Would we need a way to specify a set of cookies in SEC()?
> > Or specify a set of pairs of kernel_func+cookie?
> > None of it might be worth it.
>
> It makes sense to me to provide a way to specify cookies in the source
> code of a BPF program.
I think it's not worth it. Think about this, if you have two fentry
programs with the same logic and you are able to *statically* define
two different cookies at compile time, the easy way to do this is:
static int my_logic(__u64 cookie) { /* do something smart that depends
on cookie value */ }
SEC("fentry/func1")
int BPF_PROG(handle_func1, ...) { return my_logic(123); }
SEC("fentry/func2")
int BPF_PROG(handle_func2, ...) {return my_logic(456); }
BPF cookie was added specifically for cases when this value is *only
known at runtime* and it's impractical/impossible to somehow embed it
into BPF program code. Let's not overcomplicate this, at least until
there is a strong use case for this.
> However, it could be a very complicated syntax and/or difficult to
> read.
> Kernel_func+cookie, even Kernel_func_pattern+cookie, pairs are easy to
> understand.
> For more complicated cases, giving cookies at user space programs would
> be a better choice.
>
