On 2024/2/14 19:25, Maciej Fijalkowski wrote: > On Wed, Feb 14, 2024 at 01:47:45PM +0800, Leon Hwang wrote: >> >> >> On 2024/1/5 12:15, Alexei Starovoitov wrote: >>> On Thu, Jan 4, 2024 at 6:23 AM Leon Hwang <hffilwlqm@xxxxxxxxx> wrote: >>>> >>>> >>> >>> Other alternatives? >> >> I've finish the POC of an alternative, which passed all tailcall >> selftests including these tailcall hierarchy ones. >> >> In this alternative, I use a new bpf_prog_run_ctx to wrap the original >> ctx and the tcc_ptr, then get the tcc_ptr and recover the original ctx >> in JIT. >> >> Then, to avoid breaking runtime with tailcall on other arch, I add an >> arch-related check bpf_jit_supports_tail_call_cnt_ptr() to determin >> whether to use bpf_prog_run_ctx. >> >> Here's the diff: > > This is diff against your previous proposed solution, would be good to see The previous proposed solution is buggy, when I have a deep analysis. > how it currently looks being put together (this diff on top of your > patch), would save us some effort to dig the patch up and include diff. > But, we can not apply this patch with this diff. It's because it breaks the runtime with tailcall of bpf progs, whose runtime entry is not __bpf_prog_run(), e.g. trampoline-based fentry/fexit/fmod_ret. So, is there any other bpf prog types whose runtime entry is not either __bpf_prog_run() or trampoline? I'd like to fix them in PATCH v2. Thanks, Leon
