On Tue, Feb 3, 2026 at 1:38 AM Jiri Olsa <[email protected]> wrote: > > hi, > as an option to Meglong's change [1] I'm sending proposal for tracing_multi > link that does not add static trampoline but attaches program to all needed > trampolines. > > This approach keeps the same performance but has some drawbacks: > > - when attaching 20k functions we allocate and attach 20k trampolines > - during attachment we hold each trampoline mutex, so for above > 20k functions we will hold 20k mutexes during the attachment, > should be very prone to deadlock, but haven't hit it yet
If you check that it's sorted and always take them in the same order then there will be no deadlock. Or just grab one global mutex first and then grab trampolines mutexes next in any order. The global one will serialize this attach operation. > It looks the trampoline allocations/generation might not be big a problem > and I'll try to find a solution for holding that many mutexes. If there's > no better solution I think having one read/write mutex for tracing multi > link attach/detach should work. If you mean to have one global mutex as I proposed above then I don't see a downside. It only serializes multiple libbpf calls. overall makes sense to me.
