1. 14 Sep, 2023 2 commits
  2. 13 Sep, 2023 1 commit
  3. 12 Sep, 2023 4 commits
    • Alexei Starovoitov's avatar
      Merge branch 'bpf-x64-fix-tailcall-infinite-loop' · 5bbb9e1f
      Alexei Starovoitov authored
      Leon Hwang says:
      
      ====================
      bpf, x64: Fix tailcall infinite loop
      
      This patch series fixes a tailcall infinite loop on x64.
      
      From commit ebf7d1f5 ("bpf, x64: rework pro/epilogue and tailcall
      handling in JIT"), the tailcall on x64 works better than before.
      
      From commit e411901c ("bpf: allow for tailcalls in BPF subprograms
      for x64 JIT"), tailcall is able to run in BPF subprograms on x64.
      
      From commit 5b92a28a ("bpf: Support attaching tracing BPF program
      to other BPF programs"), BPF program is able to trace other BPF programs.
      
      How about combining them all together?
      
      1. FENTRY/FEXIT on a BPF subprogram.
      2. A tailcall runs in the BPF subprogram.
      3. The tailcall calls the subprogram's caller.
      
      As a result, a tailcall infinite loop comes up. And the loop would halt
      the machine.
      
      As we know, in tail call context, the tail_call_cnt propagates by stack
      and rax register between BPF subprograms. So do in trampolines.
      
      How did I discover the bug?
      
      From commit 7f6e4312 ("bpf: Limit caller's stack depth 256 for
      subprogs with tailcalls"), the total stack size limits to around 8KiB.
      Then, I write some bpf progs to validate the stack consuming, that are
      tailcalls running in bpf2bpf and FENTRY/FEXIT tracing on bpf2bpf.
      
      At that time, accidently, I made a tailcall loop. And then the loop halted
      my VM. Without the loop, the bpf progs would consume over 8KiB stack size.
      But the _stack-overflow_ did not halt my VM.
      
      With bpf_printk(), I confirmed that the tailcall count limit did not work
      expectedly. Next, read the code and fix it.
      
      Thank Ilya Leoshkevich, this bug on s390x has been fixed.
      
      Hopefully, this bug on arm64 will be fixed in near future.
      ====================
      
      Link: https://lore.kernel.org/r/20230912150442.2009-1-hffilwlqm@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      5bbb9e1f
    • Leon Hwang's avatar
      selftests/bpf: Add testcases for tailcall infinite loop fixing · e13b5f2f
      Leon Hwang authored
      Add 4 test cases to confirm the tailcall infinite loop bug has been fixed.
      
      Like tailcall_bpf2bpf cases, do fentry/fexit on the bpf2bpf, and then
      check the final count result.
      
      tools/testing/selftests/bpf/test_progs -t tailcalls
      226/13  tailcalls/tailcall_bpf2bpf_fentry:OK
      226/14  tailcalls/tailcall_bpf2bpf_fexit:OK
      226/15  tailcalls/tailcall_bpf2bpf_fentry_fexit:OK
      226/16  tailcalls/tailcall_bpf2bpf_fentry_entry:OK
      226     tailcalls:OK
      Summary: 1/16 PASSED, 0 SKIPPED, 0 FAILED
      Signed-off-by: default avatarLeon Hwang <hffilwlqm@gmail.com>
      Link: https://lore.kernel.org/r/20230912150442.2009-4-hffilwlqm@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      e13b5f2f
    • Leon Hwang's avatar
      bpf, x64: Fix tailcall infinite loop · 2b5dcb31
      Leon Hwang authored
      From commit ebf7d1f5 ("bpf, x64: rework pro/epilogue and tailcall
      handling in JIT"), the tailcall on x64 works better than before.
      
      From commit e411901c ("bpf: allow for tailcalls in BPF subprograms
      for x64 JIT"), tailcall is able to run in BPF subprograms on x64.
      
      From commit 5b92a28a ("bpf: Support attaching tracing BPF program
      to other BPF programs"), BPF program is able to trace other BPF programs.
      
      How about combining them all together?
      
      1. FENTRY/FEXIT on a BPF subprogram.
      2. A tailcall runs in the BPF subprogram.
      3. The tailcall calls the subprogram's caller.
      
      As a result, a tailcall infinite loop comes up. And the loop would halt
      the machine.
      
      As we know, in tail call context, the tail_call_cnt propagates by stack
      and rax register between BPF subprograms. So do in trampolines.
      
      Fixes: ebf7d1f5 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
      Fixes: e411901c ("bpf: allow for tailcalls in BPF subprograms for x64 JIT")
      Reviewed-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Signed-off-by: default avatarLeon Hwang <hffilwlqm@gmail.com>
      Link: https://lore.kernel.org/r/20230912150442.2009-3-hffilwlqm@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2b5dcb31
    • Leon Hwang's avatar
      bpf, x64: Comment tail_call_cnt initialisation · 2bee9770
      Leon Hwang authored
      Without understanding emit_prologue(), it is really hard to figure out
      where does tail_call_cnt come from, even though searching tail_call_cnt
      in the whole kernel repo.
      
      By adding these comments, it is a little bit easier to understand
      tail_call_cnt initialisation.
      Signed-off-by: default avatarLeon Hwang <hffilwlqm@gmail.com>
      Link: https://lore.kernel.org/r/20230912150442.2009-2-hffilwlqm@gmail.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2bee9770
  4. 11 Sep, 2023 1 commit
  5. 09 Sep, 2023 2 commits
  6. 08 Sep, 2023 30 commits