On Sat, 15 Jul 2023 at 03:18, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Jul 13, 2023 at 06:01:17AM +0530, Kumar Kartikeya Dwivedi wrote: > > While the check_max_stack_depth function explores call chains emanating > > from the main prog, which is typically enough to cover all possible call > > chains, it doesn't explore those rooted at async callbacks unless the > > async callback will have been directly called, since unlike non-async > > callbacks it skips their instruction exploration as they don't > > contribute to stack depth. > > > > It could be the case that the async callback leads to a callchain which > > exceeds the stack depth, but this is never reachable while only > > exploring the entry point from main subprog. Hence, repeat the check for > > the main subprog *and* all async callbacks marked by the symbolic > > execution pass of the verifier, as execution of the program may begin at > > any of them. > > > > Consider a function with following stack depths: > > main : 256 > > async : 256 > > foo: 256 > > > > main: > > rX = async > > bpf_timer_set_callback(...) > > > > async: > > foo() > > > > Here, async is never seen to contribute to the stack depth of main, so > > it is not descended, but when async is invoked asynchronously when the > > timer fires, it will end up breaching MAX_BPF_STACK limit imposed by the > > verifier. > > The fix is correct, but the above paragraph is misleading. > async doesn't and shouldn't contribute to the stack depth of main prog. > Could you rephrase it? > Agreed, I sent a v2 with a clearer commit message.
