| Message ID | 20240831041934.1629216-1-pulehui@huaweicloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix accessing first syscall argument on RV64 | expand |
Hello: This series was applied to bpf/bpf-next.git (master) by Andrii Nakryiko <andrii@kernel.org>: On Sat, 31 Aug 2024 04:19:30 +0000 you wrote: > On RV64, as Ilya mentioned before [0], the first syscall parameter should be > accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), > otherwise it will cause selftests like bpf_syscall_macro, vmlinux, > test_lsm, etc. to fail on RV64. > > Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] > > [...] Here is the summary with links: - [bpf-next,v3,1/4] libbpf: Access first syscall argument with CO-RE direct read on s390 https://git.kernel.org/bpf/bpf-next/c/65ee11d9c822 - [bpf-next,v3,2/4] libbpf: Access first syscall argument with CO-RE direct read on arm64 https://git.kernel.org/bpf/bpf-next/c/ebd8ad474888 - [bpf-next,v3,3/4] selftests/bpf: Enable test_bpf_syscall_macro:syscall_arg1 on s390 and arm64 https://git.kernel.org/bpf/bpf-next/c/3a913c4d62e1 - [bpf-next,v3,4/4] libbpf: Fix accessing first syscall argument on RV64 https://git.kernel.org/bpf/bpf-next/c/13143c5816bc You are awesome, thank you!
On Wed, Sep 4, 2024 at 3:44 PM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > > On Wed, Sep 4, 2024 at 1:30 PM <patchwork-bot+netdevbpf@kernel.org> wrote: > > > > Hello: > > > > This series was applied to bpf/bpf-next.git (master) > > by Andrii Nakryiko <andrii@kernel.org>: > > > > On Sat, 31 Aug 2024 04:19:30 +0000 you wrote: > > > On RV64, as Ilya mentioned before [0], the first syscall parameter should be > > > accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), > > > otherwise it will cause selftests like bpf_syscall_macro, vmlinux, > > > test_lsm, etc. to fail on RV64. > > > > > > Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] > > > > > > [...] > > > > Here is the summary with links: > > - [bpf-next,v3,1/4] libbpf: Access first syscall argument with CO-RE direct read on s390 > > https://git.kernel.org/bpf/bpf-next/c/65ee11d9c822 > > - [bpf-next,v3,2/4] libbpf: Access first syscall argument with CO-RE direct read on arm64 > > https://git.kernel.org/bpf/bpf-next/c/ebd8ad474888 > > - [bpf-next,v3,3/4] selftests/bpf: Enable test_bpf_syscall_macro:syscall_arg1 on s390 and arm64 > > https://git.kernel.org/bpf/bpf-next/c/3a913c4d62e1 > > - [bpf-next,v3,4/4] libbpf: Fix accessing first syscall argument on RV64 > > https://git.kernel.org/bpf/bpf-next/c/13143c5816bc > > > > Ok, I had to "unapply" these patches, as s390x selftest (bpf_syscall_macro) started failing (arm64 is fine, so I think it's probably due to patch #3 that changes selftests itself). > > Pu, can you please take a look at that (e.g., see [0])? It's a bit strange, as originally no error was reported, so not sure what changed. Please also see the things I was fixing up while applying, so I don't have to do it again :) > > [0] https://github.com/kernel-patches/bpf/actions/runs/10709024755/job/29693056550#step:5:8746 Oh, I figured it out! That tmp is there for a reason! We bpf_probe_read_kernel() 8 bytes, but syscall's 1st argument itself is 4 byte long, so we need to cast u64 to u32. And s390x being the big endian architecture detected this problem, while for arm64 we were lucky. So never mind, I'll apply your patches with fix ups in the bpf_tracing.h header, but I won't touch patch #3. > > > You are awesome, thank you! > > -- > > Deet-doot-dot, I am a bot. > > https://korg.docs.kernel.org/patchwork/pwbot.html > > > >
On 2024/9/5 8:03, Andrii Nakryiko wrote: > On Wed, Sep 4, 2024 at 3:44 PM Andrii Nakryiko > <andrii.nakryiko@gmail.com> wrote: >> >> >> >> On Wed, Sep 4, 2024 at 1:30 PM <patchwork-bot+netdevbpf@kernel.org> wrote: >>> >>> Hello: >>> >>> This series was applied to bpf/bpf-next.git (master) >>> by Andrii Nakryiko <andrii@kernel.org>: >>> >>> On Sat, 31 Aug 2024 04:19:30 +0000 you wrote: >>>> On RV64, as Ilya mentioned before [0], the first syscall parameter should be >>>> accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), >>>> otherwise it will cause selftests like bpf_syscall_macro, vmlinux, >>>> test_lsm, etc. to fail on RV64. >>>> >>>> Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] >>>> >>>> [...] >>> >>> Here is the summary with links: >>> - [bpf-next,v3,1/4] libbpf: Access first syscall argument with CO-RE direct read on s390 >>> https://git.kernel.org/bpf/bpf-next/c/65ee11d9c822 >>> - [bpf-next,v3,2/4] libbpf: Access first syscall argument with CO-RE direct read on arm64 >>> https://git.kernel.org/bpf/bpf-next/c/ebd8ad474888 >>> - [bpf-next,v3,3/4] selftests/bpf: Enable test_bpf_syscall_macro:syscall_arg1 on s390 and arm64 >>> https://git.kernel.org/bpf/bpf-next/c/3a913c4d62e1 >>> - [bpf-next,v3,4/4] libbpf: Fix accessing first syscall argument on RV64 >>> https://git.kernel.org/bpf/bpf-next/c/13143c5816bc >>> >> >> Ok, I had to "unapply" these patches, as s390x selftest (bpf_syscall_macro) started failing (arm64 is fine, so I think it's probably due to patch #3 that changes selftests itself). >> >> Pu, can you please take a look at that (e.g., see [0])? It's a bit strange, as originally no error was reported, so not sure what changed. Please also see the things I was fixing up while applying, so I don't have to do it again :) >> >> [0] https://github.com/kernel-patches/bpf/actions/runs/10709024755/job/29693056550#step:5:8746 > > Oh, I figured it out! That tmp is there for a reason! We > bpf_probe_read_kernel() 8 bytes, but syscall's 1st argument itself is > 4 byte long, so we need to cast u64 to u32. And s390x being the big > endian architecture detected this problem, while for arm64 we were > lucky. > > So never mind, I'll apply your patches with fix ups in the > bpf_tracing.h header, but I won't touch patch #3. Sorry for couldn't reply in time due to jet lag. Glad the issue didn't block in the end.
Hello: This series was applied to riscv/linux.git (fixes) by Andrii Nakryiko <andrii@kernel.org>: On Sat, 31 Aug 2024 04:19:30 +0000 you wrote: > On RV64, as Ilya mentioned before [0], the first syscall parameter should be > accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), > otherwise it will cause selftests like bpf_syscall_macro, vmlinux, > test_lsm, etc. to fail on RV64. > > Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] > > [...] Here is the summary with links: - [bpf-next,v3,1/4] libbpf: Access first syscall argument with CO-RE direct read on s390 https://git.kernel.org/riscv/c/e4db2a821b6c - [bpf-next,v3,2/4] libbpf: Access first syscall argument with CO-RE direct read on arm64 https://git.kernel.org/riscv/c/9ab94078e868 - [bpf-next,v3,3/4] selftests/bpf: Enable test_bpf_syscall_macro:syscall_arg1 on s390 and arm64 https://git.kernel.org/riscv/c/4a4c4c0d0a42 - [bpf-next,v3,4/4] libbpf: Fix accessing first syscall argument on RV64 https://git.kernel.org/riscv/c/99857422338b You are awesome, thank you!
On RV64, as Ilya mentioned before [0], the first syscall parameter should be accessed through orig_a0 (see arch/riscv64/include/asm/syscall.h), otherwise it will cause selftests like bpf_syscall_macro, vmlinux, test_lsm, etc. to fail on RV64. Link: https://lore.kernel.org/bpf/20220209021745.2215452-1-iii@linux.ibm.com [0] v3: - Fix test case error. v2: https://lore.kernel.org/all/20240831023646.1558629-1-pulehui@huaweicloud.com/ - Access first syscall argument with CO-RE direct read. (Andrii) v1: https://lore.kernel.org/all/20240829133453.882259-1-pulehui@huaweicloud.com/ Pu Lehui (4): libbpf: Access first syscall argument with CO-RE direct read on s390 libbpf: Access first syscall argument with CO-RE direct read on arm64 selftests/bpf: Enable test_bpf_syscall_macro:syscall_arg1 on s390 and arm64 libbpf: Fix accessing first syscall argument on RV64 tools/lib/bpf/bpf_tracing.h | 17 ++++++++++++----- .../bpf/prog_tests/test_bpf_syscall_macro.c | 4 ---- .../selftests/bpf/progs/bpf_syscall_macro.c | 2 -- 3 files changed, 12 insertions(+), 11 deletions(-)