On Wed, Apr 10, 2024 at 7:09 AM Leon Hwang <hffilwlqm@xxxxxxxxx> wrote: > > > > On 2024/4/8 00:30, Alexei Starovoitov wrote: > > On Sun, Apr 7, 2024 at 4:34 AM Leon Hwang <hffilwlqm@xxxxxxxxx> wrote: > >> > >> > >> > >> On 2024/4/5 09:03, Alexei Starovoitov wrote: > >>>> * Solution changes from percpu tail_call_cnt to tail_call_cnt at task_struct. > >>> > >>> Please remind us what was wrong with per-cpu approach? > >> > >> There are some cases that the per-cpu approach cannot handle properly. > >> Especialy, on non-SMP machine, if there are many bpf progs to run with > >> tail call simultaneously, MAX_TAIL_CALL_CNT limit is unable to limit the > >> tail call expectedly. > > > > That's not a very helpful explanation. > > I apologize for my poor communication skill. I hope I can help to fix > this issue. > > Why did I raise this approach, tcc in task_struct? When I tried to > figure out a better position to store tcc instead as a stack variable or > a per-cpu variable, why not store it in runtime context? > Around a tail call, the tail caller and the tail callee run on the same > thread, and the thread won't be migrated because of migrate_disable(), > if I understand correctly. As a consequence, it's better to store tcc in > thread struct or in thread local storage. In kernel, task_struct is the > thread struct, if I understand correctly. Thereafter, when multiple > progs tail_call-ing on the same cpu, the per-task tcc should limit them > independently, e.g. > > prog1 prog2 > thread1 thread2 > | | > |--sched->| > | | > |<-sched--| > | | > --------------- > CPU1 > > NOTE: prog1 is diff from prog2. And they have tail call to handle while > they're scheduled. > > The tcc in thread2 would not override the tcc in thread1. > > When the same scenario as the above diagram shows happens to per-cpu tcc > approach, the tcc in thread2 will override the tcc in thread1. As a > result, per-cpu tcc cannot limit the tail call in thread1 and thread2 > independently. This is what I concern about per-cpu tcc approach. The same issue exists with per-task tcc. In the above example prog1 and prog2 can be in the same thread1. Example: prog1 is a kprobe-prog and prog2 is fentry prog that attaches to something that prog1 is going to call. When prog2 starts it will overwrite tcc in task. So same issue as with per-cpu tcc.
