mbox series

[bpf-next,v3,0/8] Support bpf trampoline for s390x

Message ID 20230129190501.1624747-1-iii@linux.ibm.com (mailing list archive)
Headers show
Series Support bpf trampoline for s390x | expand

Message

Ilya Leoshkevich Jan. 29, 2023, 7:04 p.m. UTC 
v2: https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
v2 -> v3:
- Make __arch_prepare_bpf_trampoline static.
  (Reported-by: kernel test robot <lkp@intel.com>)
- Support both old- and new- style map definitions in sk_assign. (Alexei)
- Trim DENYLIST.s390x. (Alexei)
- Adjust s390x vmlinux path in vmtest.sh.
- Drop merged fixes.

v1: https://lore.kernel.org/bpf/20230125213817.1424447-1-iii@linux.ibm.com/#t
v1 -> v2:
- Fix core_read_macros, sk_assign, test_profiler, test_bpffs (24/31;
  I'm not quite happy with the fix, but don't have better ideas),
  and xdp_synproxy. (Andrii)
- Prettify liburandom_read and verify_pkcs7_sig fixes. (Andrii)
- Fix bpf_usdt_arg using barrier_var(); prettify barrier_var(). (Andrii)
- Change BPF_MAX_TRAMP_LINKS to enum and query it using BTF. (Andrii)
- Improve bpf_jit_supports_kfunc_call() description. (Alexei)
- Always check sign_extend() return value.
- Cc: Alexander Gordeev.

Hi,

This series implements poke, trampoline, kfunc, and mixing subprogs
and tailcalls on s390x.

The following failures still remain:

#82      get_stack_raw_tp:FAIL
get_stack_print_output:FAIL:user_stack corrupted user stack
Known issue:
We cannot reliably unwind userspace on s390x without DWARF.

#101     ksyms_module:FAIL
address of kernel function bpf_testmod_test_mod_kfunc is out of range
Known issue:
Kernel and modules are too far away from each other on s390x.

#190     stacktrace_build_id:FAIL
Known issue:
We cannot reliably unwind userspace on s390x without DWARF.

#281     xdp_metadata:FAIL
See patch 6.

None of these seem to be due to the new changes.

Best regards,
Ilya

Ilya Leoshkevich (8):
  selftests/bpf: Fix sk_assign on s390x
  s390/bpf: Add expoline to tail calls
  s390/bpf: Implement bpf_arch_text_poke()
  s390/bpf: Implement arch_prepare_bpf_trampoline()
  s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()
  s390/bpf: Implement bpf_jit_supports_kfunc_call()
  selftests/bpf: Fix s390x vmlinux path
  selftests/bpf: Trim DENYLIST.s390x

 arch/s390/net/bpf_jit_comp.c                  | 713 +++++++++++++++++-
 include/linux/bpf.h                           |   4 +
 tools/testing/selftests/bpf/DENYLIST.s390x    |  69 --
 .../selftests/bpf/prog_tests/sk_assign.c      |  25 +-
 .../selftests/bpf/progs/test_sk_assign.c      |  11 +
 .../bpf/progs/test_sk_assign_libbpf.c         |   3 +
 tools/testing/selftests/bpf/vmtest.sh         |   2 +-
 7 files changed, 715 insertions(+), 112 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/test_sk_assign_libbpf.c

Comments

Alexei Starovoitov Jan. 30, 2023, 3:28 a.m. UTC | #1 
On Sun, Jan 29, 2023 at 11:05 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> v2: https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> v2 -> v3:
> - Make __arch_prepare_bpf_trampoline static.
>   (Reported-by: kernel test robot <lkp@intel.com>)
> - Support both old- and new- style map definitions in sk_assign. (Alexei)
> - Trim DENYLIST.s390x. (Alexei)
> - Adjust s390x vmlinux path in vmtest.sh.
> - Drop merged fixes.

It looks great. Applied.

Sadly clang repo is unreliable today. I've kicked BPF CI multiple times,
but it didn't manage to fetch the clang. Pushed anyway.
Pls watch for BPF CI failures in future runs.
patchwork-bot+netdevbpf@kernel.org Jan. 30, 2023, 3:30 a.m. UTC | #2 
Hello:

This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Sun, 29 Jan 2023 20:04:53 +0100 you wrote:
> v2: https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> v2 -> v3:
> - Make __arch_prepare_bpf_trampoline static.
>   (Reported-by: kernel test robot <lkp@intel.com>)
> - Support both old- and new- style map definitions in sk_assign. (Alexei)
> - Trim DENYLIST.s390x. (Alexei)
> - Adjust s390x vmlinux path in vmtest.sh.
> - Drop merged fixes.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v3,1/8] selftests/bpf: Fix sk_assign on s390x
    https://git.kernel.org/bpf/bpf-next/c/7ce878ca81bc
  - [bpf-next,v3,2/8] s390/bpf: Add expoline to tail calls
    https://git.kernel.org/bpf/bpf-next/c/bb4ef8fc3d19
  - [bpf-next,v3,3/8] s390/bpf: Implement bpf_arch_text_poke()
    https://git.kernel.org/bpf/bpf-next/c/f1d5df84cd8c
  - [bpf-next,v3,4/8] s390/bpf: Implement arch_prepare_bpf_trampoline()
    https://git.kernel.org/bpf/bpf-next/c/528eb2cb87bc
  - [bpf-next,v3,5/8] s390/bpf: Implement bpf_jit_supports_subprog_tailcalls()
    https://git.kernel.org/bpf/bpf-next/c/dd691e847d28
  - [bpf-next,v3,6/8] s390/bpf: Implement bpf_jit_supports_kfunc_call()
    https://git.kernel.org/bpf/bpf-next/c/63d7b53ab59f
  - [bpf-next,v3,7/8] selftests/bpf: Fix s390x vmlinux path
    https://git.kernel.org/bpf/bpf-next/c/af320fb7ddb0
  - [bpf-next,v3,8/8] selftests/bpf: Trim DENYLIST.s390x
    https://git.kernel.org/bpf/bpf-next/c/ee105d5a50d4

You are awesome, thank you!
Ilya Leoshkevich Jan. 30, 2023, 6:56 p.m. UTC | #3 
On Sun, 2023-01-29 at 19:28 -0800, Alexei Starovoitov wrote:
> On Sun, Jan 29, 2023 at 11:05 AM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> > 
> > v2:
> > https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> > v2 -> v3:
> > - Make __arch_prepare_bpf_trampoline static.
> >   (Reported-by: kernel test robot <lkp@intel.com>)
> > - Support both old- and new- style map definitions in sk_assign.
> > (Alexei)
> > - Trim DENYLIST.s390x. (Alexei)
> > - Adjust s390x vmlinux path in vmtest.sh.
> > - Drop merged fixes.
> 
> It looks great. Applied.
> 
> Sadly clang repo is unreliable today. I've kicked BPF CI multiple
> times,
> but it didn't manage to fetch the clang. Pushed anyway.
> Pls watch for BPF CI failures in future runs.

I think this is because llvm-toolchain-focal contains llvm 17 now.
So we need to either use llvm-toolchain-focal-16, or set
llvm_default_version=16 in libbpf/ci.
Alexei Starovoitov Jan. 31, 2023, 3:13 a.m. UTC | #4 
On Mon, Jan 30, 2023 at 10:56 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> On Sun, 2023-01-29 at 19:28 -0800, Alexei Starovoitov wrote:
> > On Sun, Jan 29, 2023 at 11:05 AM Ilya Leoshkevich <iii@linux.ibm.com>
> > wrote:
> > >
> > > v2:
> > > https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> > > v2 -> v3:
> > > - Make __arch_prepare_bpf_trampoline static.
> > >   (Reported-by: kernel test robot <lkp@intel.com>)
> > > - Support both old- and new- style map definitions in sk_assign.
> > > (Alexei)
> > > - Trim DENYLIST.s390x. (Alexei)
> > > - Adjust s390x vmlinux path in vmtest.sh.
> > > - Drop merged fixes.
> >
> > It looks great. Applied.
> >
> > Sadly clang repo is unreliable today. I've kicked BPF CI multiple
> > times,
> > but it didn't manage to fetch the clang. Pushed anyway.
> > Pls watch for BPF CI failures in future runs.
>
> I think this is because llvm-toolchain-focal contains llvm 17 now.
> So we need to either use llvm-toolchain-focal-16, or set
> llvm_default_version=16 in libbpf/ci.

Yep. That was fixed.
Looks like only one test is failing on s390:
test_synproxy:PASS:./xdp_synproxy --iface tmp1 --single 0 nsec
expect_str:FAIL:SYNACKs after connection unexpected SYNACKs after
connection: actual '' != expected 'Total SYNACKs generated: 1\x0A'

#284/1 xdp_synproxy/xdp:FAIL
#284 xdp_synproxy:FAIL
Summary: 260/1530 PASSED, 31 SKIPPED, 1 FAILED
Ilya Leoshkevich Jan. 31, 2023, 1:36 p.m. UTC | #5 
On Mon, 2023-01-30 at 19:13 -0800, Alexei Starovoitov wrote:
> On Mon, Jan 30, 2023 at 10:56 AM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> > 
> > On Sun, 2023-01-29 at 19:28 -0800, Alexei Starovoitov wrote:
> > > On Sun, Jan 29, 2023 at 11:05 AM Ilya Leoshkevich
> > > <iii@linux.ibm.com>
> > > wrote:
> > > > 
> > > > v2:
> > > > https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> > > > v2 -> v3:
> > > > - Make __arch_prepare_bpf_trampoline static.
> > > >   (Reported-by: kernel test robot <lkp@intel.com>)
> > > > - Support both old- and new- style map definitions in
> > > > sk_assign.
> > > > (Alexei)
> > > > - Trim DENYLIST.s390x. (Alexei)
> > > > - Adjust s390x vmlinux path in vmtest.sh.
> > > > - Drop merged fixes.
> > > 
> > > It looks great. Applied.
> > > 
> > > Sadly clang repo is unreliable today. I've kicked BPF CI multiple
> > > times,
> > > but it didn't manage to fetch the clang. Pushed anyway.
> > > Pls watch for BPF CI failures in future runs.
> > 
> > I think this is because llvm-toolchain-focal contains llvm 17 now.
> > So we need to either use llvm-toolchain-focal-16, or set
> > llvm_default_version=16 in libbpf/ci.
> 
> Yep. That was fixed.
> Looks like only one test is failing on s390:
> test_synproxy:PASS:./xdp_synproxy --iface tmp1 --single 0 nsec
> expect_str:FAIL:SYNACKs after connection unexpected SYNACKs after
> connection: actual '' != expected 'Total SYNACKs generated: 1\x0A'
> 
> #284/1 xdp_synproxy/xdp:FAIL
> #284 xdp_synproxy:FAIL
> Summary: 260/1530 PASSED, 31 SKIPPED, 1 FAILED

Thanks! Where do you see the xdp_synproxy failure? I checked the jobs
at [1] and rather see two migrate_reuseport failures ([2], [3]):

  count_requests:FAIL:count in BPF prog unexpected count in BPF prog:
actual 10 != expected 25
  #127/7   migrate_reuseport/IPv6 TCP_NEW_SYN_RECV
reqsk_timer_handler:FAIL

  count_requests:FAIL:count in BPF prog unexpected count in BPF prog:
actual 14 != expected 25
  #127/4   migrate_reuseport/IPv4 TCP_NEW_SYN_RECV
inet_csk_complete_hashdance:FAIL

I tried running vmtest.sh in a loop, and could not reproduce neither
the xdp_synproxy nor the migrate_reuseport failure.

In migrate_reuseport, from the userspace perspective everything works,
(count_requests:PASS:count in userspace 0 nsec). This means that we
always get to the bpf_sk_select_reuseport() call and it succeeds.
The eBPF program still records at least some migrations while the
connection is in the TCP_NEW_SYN_RECV state, so I wonder if other
migrations, for whatever reason, happen in a different state?

[1] https://github.com/libbpf/libbpf/actions/workflows/test.yml
[2]
https://github.com/libbpf/libbpf/actions/runs/4049227053/jobs/6965361085#step:30:8908
[3]
https://github.com/libbpf/libbpf/actions/runs/4049783307/jobs/6966526594#step:30:8911
Joanne Koong Feb. 2, 2023, 6:29 p.m. UTC | #6 
On Tue, Jan 31, 2023 at 5:47 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> On Mon, 2023-01-30 at 19:13 -0800, Alexei Starovoitov wrote:
> > On Mon, Jan 30, 2023 at 10:56 AM Ilya Leoshkevich <iii@linux.ibm.com>
> > wrote:
> > >
> > > On Sun, 2023-01-29 at 19:28 -0800, Alexei Starovoitov wrote:
> > > > On Sun, Jan 29, 2023 at 11:05 AM Ilya Leoshkevich
> > > > <iii@linux.ibm.com>
> > > > wrote:
> > > > >
> > > > > v2:
> > > > > https://lore.kernel.org/bpf/20230128000650.1516334-1-iii@linux.ibm.com/#t
> > > > > v2 -> v3:
> > > > > - Make __arch_prepare_bpf_trampoline static.
> > > > >   (Reported-by: kernel test robot <lkp@intel.com>)
> > > > > - Support both old- and new- style map definitions in
> > > > > sk_assign.
> > > > > (Alexei)
> > > > > - Trim DENYLIST.s390x. (Alexei)
> > > > > - Adjust s390x vmlinux path in vmtest.sh.
> > > > > - Drop merged fixes.
> > > >
> > > > It looks great. Applied.
> > > >
> > > > Sadly clang repo is unreliable today. I've kicked BPF CI multiple
> > > > times,
> > > > but it didn't manage to fetch the clang. Pushed anyway.
> > > > Pls watch for BPF CI failures in future runs.
> > >
> > > I think this is because llvm-toolchain-focal contains llvm 17 now.
> > > So we need to either use llvm-toolchain-focal-16, or set
> > > llvm_default_version=16 in libbpf/ci.
> >
> > Yep. That was fixed.
> > Looks like only one test is failing on s390:
> > test_synproxy:PASS:./xdp_synproxy --iface tmp1 --single 0 nsec
> > expect_str:FAIL:SYNACKs after connection unexpected SYNACKs after
> > connection: actual '' != expected 'Total SYNACKs generated: 1\x0A'
> >
> > #284/1 xdp_synproxy/xdp:FAIL
> > #284 xdp_synproxy:FAIL
> > Summary: 260/1530 PASSED, 31 SKIPPED, 1 FAILED
>
> Thanks! Where do you see the xdp_synproxy failure? I checked the jobs
> at [1] and rather see two migrate_reuseport failures ([2], [3]):

Hi Ilya,

I'm seeing these xdp_synproxy failures consistently in CI on
"test_progs/test_progs_no_alu32 on s390x with gcc" builds. These links
are to some of the latest ones:

https://github.com/kernel-patches/bpf/actions/runs/4074723783/jobs/7021760646
https://github.com/kernel-patches/bpf/actions/runs/4073866949/jobs/7019322847
https://github.com/kernel-patches/bpf/actions/runs/4073861356/jobs/7018721175

>
>   count_requests:FAIL:count in BPF prog unexpected count in BPF prog:
> actual 10 != expected 25
>   #127/7   migrate_reuseport/IPv6 TCP_NEW_SYN_RECV
> reqsk_timer_handler:FAIL
>
>   count_requests:FAIL:count in BPF prog unexpected count in BPF prog:
> actual 14 != expected 25
>   #127/4   migrate_reuseport/IPv4 TCP_NEW_SYN_RECV
> inet_csk_complete_hashdance:FAIL
>
> I tried running vmtest.sh in a loop, and could not reproduce neither
> the xdp_synproxy nor the migrate_reuseport failure.
>
> In migrate_reuseport, from the userspace perspective everything works,
> (count_requests:PASS:count in userspace 0 nsec). This means that we
> always get to the bpf_sk_select_reuseport() call and it succeeds.
> The eBPF program still records at least some migrations while the
> connection is in the TCP_NEW_SYN_RECV state, so I wonder if other
> migrations, for whatever reason, happen in a different state?
>
> [1] https://github.com/libbpf/libbpf/actions/workflows/test.yml
> [2]
> https://github.com/libbpf/libbpf/actions/runs/4049227053/jobs/6965361085#step:30:8908
> [3]
> https://github.com/libbpf/libbpf/actions/runs/4049783307/jobs/6966526594#step:30:8911