On Mon, Aug 08, 2022 at 10:50:28AM -0700, Song Liu wrote: > On Mon, Aug 8, 2022 at 7:06 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > [...] > > > > Maybe better explained on following example: > > > > - you want to attach program P to functions A,B,C,D,E,F > > via bpf_trampoline_multi_attach > > > > - D,E,F already have standard trampoline attached > > > > - the bpf_trampoline_multi_attach will create new 'multi' trampoline > > which spans over A,B,C functions and attach program P to single > > trampolines D,E,F > > IIUC, we have 4 trampolines (1 multi, 3 singles) at this moment? yes > > > > > - another program can be attached to A,B,C,D,E,F multi trampoline > > > > - A,B,C functions are now 'not attachable' by any trampoline > > until the above 'multi' trampoline is released > > I guess the limitation here is, multi trampolines cannot be splitted after > attached. While multi trampoline is motivated by short term use cases > like retsnoop, it is allowed to run them for extended periods of time. > Then, this limitation might be a real issue in production. I think it'd be possible to allow adding single trampoline on top of multi trampoline by removing that single id from it and creating single trampoline for that I also thought of possibility to convert intersection IDs of two multi trampolines into single trampolines.. but that might get slow if the common set is too big the difficulty for the common solution was that if you allow to split trampolines then bpf link can't carry pointers to trampolines because they can be split into multiple new trampolines, so link would need to store just array of IDs and use it to attach a program then un/linking program and doing intersections with stored trampolines and handling all the split cases turned out to be nightmare but perhaps there's another solution jirka
