[PATCH bpf-next v3 0/4] Fix accessing first syscall argument on RV64

[Pu Lehui]

On 2024/9/5 8:03, Andrii Nakryiko wrote:
> On Wed, Sep 4, 2024 at 3:44 PM Andrii Nakryiko
> <andrii.nakryiko at gmail.com> wrote:
>>
>>
>>
>> On Wed, Sep 4, 2024 at 1:30 PM <patchwork-bot+netdevbpf at kernel.org> wrote:
>>>
>>> Hello:
>>>
>>> This series was applied to bpf/bpf-next.git (master)
>>> by Andrii Nakryiko <andrii at 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.😄

> 
>>
>>> You are awesome, thank you!
>>> --
>>> Deet-doot-dot, I am a bot.
>>> https://korg.docs.kernel.org/patchwork/pwbot.html
>>>
>>>