On Wed, Sep 4, 2024 at 3:44 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Wed, Sep 4, 2024 at 1:30 PM <patchwork-bot+netdevbpf@xxxxxxxxxx> wrote: > > > > Hello: > > > > This series was applied to bpf/bpf-next.git (master) > > by Andrii Nakryiko <andrii@xxxxxxxxxx>: > > > > 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@xxxxxxxxxxxxx [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 > > > >
