linux-kernel - Re: sparc: bpf_jit: Move four assignments in bpf_jit

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:   Sun, 4 Sep 2016 07:45:04 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Julian Calaby <julian.calaby@...il.com>
Cc:     sparclinux <sparclinux@...r.kernel.org>,
        Adam Buchbinder <adam.buchbinder@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>,
        Rabin Vincent <rabin@....in>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors <kernel-janitors@...r.kernel.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

>> I hope so. - I propose to give the refactorings "Reduce scope of variable"
>> and "Extract a function" (and the corresponding consequences) another look.
> 
> So you _think_ it does. Come back with real proof.

Which test environments would you find acceptable for further clarification?


> I must also point out that these sorts of optimisations are things the
> compiler does automatically when compiling this code.

Do you take this detail for granted?


> Therefore it's highly likely that this change will make absolutely
> no difference whatsoever.

I find this outcome unlikely.


> (And no it won't improve compile speed in any justifiable way)

This was not a goal of my update suggestion for the function "bpf_jit_compile".


>> It is generally possible that a specific code generation variant will also affect
>> the run time properties you mentioned.
> 
> It's _possible_? Come back with benchmarks.

Which code generation variant would be useful to be clarified further?

Should we avoid to compare software things similar to "apples" and "oranges"
(while these fruits can make more fun)?   ;-)


> I must also point out that this is a "slow path" i.e. as long as it's
> not stupidly inefficient, the speed doesn't matter that much.

Can this execution path become warmer (or even "hot") for some other use cases?


> This change isn't going to improve the speed of this function by any amount
> that matters.

This is also possible.


> Unless you have some pretty damn good proof that these changes improve things,
> there is absolutely no reason to take them as-is

Would you care for a better source code structure?


> - you are making the code longer

Yes. - This is true for the suggested update in this function.


> and more difficult to read for no benefit

I proposed specific benefits for this software module.


> and wasting everyone's time in the process.

I assume that a few contributors can take the presented ideas for further considerations.
Will their value evolve a bit more later?

Regards,
Markus