linux-kernel - Re: [PATCH] powerpc/bpf: Only update ldimm64 during extra pass when it is an address

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]

Date:   Thu, 24 Nov 2022 12:24:40 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>
CC:     Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Hao Luo <haoluo@...gle.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jiri Olsa <jolsa@...nel.org>, KP Singh <kpsingh@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Stanislav Fomichev <sdf@...gle.com>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>
Subject: Re: [PATCH] powerpc/bpf: Only update ldimm64 during extra pass when
 it is an address



Le 24/11/2022 à 11:13, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> ldimm64 is not only used for loading function addresses, and
> 
> That's probably true today, but I worry that that can change upstream 
> and we may not notice at all.

Not sure what you mean.

Today POWERPC considers that ldimm64 is _always_ loading a function 
address whereas upstream BPF considers that ldimm64 is a function only 
when it is flagged BPF_PSEUDO_FUNC.

In what direction could that change in the future ?

For me if they change that it becomes an API change.

Christophe


> 
>> the NOPs added for padding are impacting performance, so avoid
>> them when not necessary.
>>
>> On QEMU mac99, with the patch:
>>
>> test_bpf: #829 ALU64_MOV_K: all immediate value magnitudes jited:1 
>> 167436810 PASS
>> test_bpf: #831 ALU64_OR_K: all immediate value magnitudes jited:1 
>> 170702940 PASS
>>
>> Without the patch:
>>
>> test_bpf: #829 ALU64_MOV_K: all immediate value magnitudes jited:1 
>> 173012360 PASS
>> test_bpf: #831 ALU64_OR_K: all immediate value magnitudes jited:1 
>> 176424090 PASS
>>
>> That's a 3.5% performance improvement.
> 
> A better approach would be to do a full JIT during the extra pass. 
> That's what most other architectures do today. And, as long as we can 
> ensure that the JIT'ed program size can never increase during the extra 
> pass, we should be ok to do a single extra pass.
> 
> 
> - Naveen