linux-kernel - Re: [PATCH bpf-next v2 2/2] riscv, bpf: inline bpf_get_smp_processor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <mb61pcyq45p6j.fsf@kernel.org>
Date: Thu, 02 May 2024 13:16:52 +0000
From: Puranjay Mohan <puranjay@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai
 Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu
 <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend
 <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav
 Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
 <jolsa@...nel.org>, Björn Töpel <bjorn@...nel.org>,
 Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, bpf@...r.kernel.org,
 linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, Pu Lehui
 <pulehui@...wei.com>
Subject: Re: [PATCH bpf-next v2 2/2] riscv, bpf: inline
 bpf_get_smp_processor_id()

Andrii Nakryiko <andrii.nakryiko@...il.com> writes:

> On Tue, Apr 30, 2024 at 10:59 AM Puranjay Mohan <puranjay@...nel.org> wrote:
>>
>> Inline the calls to bpf_get_smp_processor_id() in the riscv bpf jit.
>>
>> RISCV saves the pointer to the CPU's task_struct in the TP (thread
>> pointer) register. This makes it trivial to get the CPU's processor id.
>> As thread_info is the first member of task_struct, we can read the
>> processor id from TP + offsetof(struct thread_info, cpu).
>>
>>           RISCV64 JIT output for `call bpf_get_smp_processor_id`
>>           ======================================================
>>
>>                 Before                           After
>>                --------                         -------
>>
>>          auipc   t1,0x848c                  ld    a5,32(tp)
>>          jalr    604(t1)
>>          mv      a5,a0
>>
>
> Nice, great find! Would you be able to do similar inlining for x86-64
> as well? Disassembling bpf_get_smp_processor_id for x86-64 shows this:
>
> Dump of assembler code for function bpf_get_smp_processor_id:
>    0xffffffff810f91a0 <+0>:     0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
>    0xffffffff810f91a5 <+5>:     65 8b 05 60 79 f3 7e    mov
> %gs:0x7ef37960(%rip),%eax        # 0x30b0c <pcpu_hot+12>
>    0xffffffff810f91ac <+12>:    48 98   cltq
>    0xffffffff810f91ae <+14>:    c3      ret
> End of assembler dump.
> We should be able to do the same in x86-64 BPF JIT. (it's actually how
> I started initially, I had a dedicated instruction reading per-cpu
> memory, but ended up with more general "calculate per-cpu address").

I feel in x86-64's case JIT can not do a (much) better job compared to the
current approach in the verifier.

On RISC-V and ARM64, JIT was able to do it better because both of these
architectures save a pointer to the task struct in a special CPU
register. As x86-64 doesn't have enough extra registers, it uses a
percpu variable to store task struct, thread_info, and the cpu
number.

P.S. - While doing this for BPF, I realized that ARM64 kernel code is
also not optimal as it is using the percpu variable and is not reading
the CPU register directly. So, I sent a patch[1] to fix it in the kernel
and get rid of the per-cpu variable in ARM64.


[1] https://lore.kernel.org/all/20240502123449.2690-2-puranjay@kernel.org/

> Anyways, great work, a small nit below.
>
> Acked-by: Andrii Nakryiko <andrii@...nel.org>

Thanks,
Puranjay