Messages in this thread | | | From | Yafang Shao <> | Date | Thu, 27 Apr 2023 23:23:31 +0800 | Subject | Re: [PATCH bpf-next 5/6] bpf: Improve tracing recursion prevention mechanism |
| |
On Thu, Apr 27, 2023 at 11:18 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Thu, 27 Apr 2023 22:22:22 +0800 > Yafang Shao <laoar.shao@gmail.com> wrote: > > > IIUC, the acquire/release pair works as follows, > > > > test_recursion_try_acquire > > [ protection area ] > > test_recursion_release > > > > After release, there will be no protection, and thus it will fail the > > tools/testing/selftests/bpf/progs/recursion.c[1] test case, because > > the recursion occurs in the bpf_prog_run() itself, > > But bpf programs are allowed to recurs. Hence, you need separate logic to > detect that. The test_recursion_*() code is for cases that are not allowed > to recurs. >
Agreed.
> > > > __bpf_prog_enter > > test_recursion_try_acquire > > [...] > > test_recursion_release > > // no protection after the release > > bpf_prog_run() > > bpf_prog_run() // the recursion can't be prevented. > > But I thought you can run a bpf_prog from another bpf_prog. So you don't > want to prevent it. You need other logic to detect if it was not suppose to > recurs. >
If so, we have to keep the prog->active to prevent it, then I'm not sure if it is worth adding test_recursion_*().
-- Regards Yafang
| |