linux-kernel - Re: [PATCH 2/4] 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]

Message-ID: <CAGRGNgUxt+qgiDHQ7qQ3a7QEJ3xZ4rRTW6RN8fTLNK6E6pgWTw@mail.gmail.com>
Date:   Sun, 4 Sep 2016 14:44:42 +1000
From:   Julian Calaby <julian.calaby@...il.com>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
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: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus,

On Sun, Sep 4, 2016 at 2:33 PM, SF Markus Elfring
<elfring@...rs.sourceforge.net> wrote:
>>> Date: Sat, 3 Sep 2016 17:45:28 +0200
>>>
>>> Move the assignments for four local variables a bit at the beginning
>>> so that they will only be performed if a corresponding memory allocation
>>> succeeded by this function.
> …
>>> @@ -362,10 +362,10 @@ do {      *prog++ = BR_OPC | WDISP22(OFF);                \
>>>
>>>  void bpf_jit_compile(struct bpf_prog *fp)
>>>  {
>>> -       unsigned int cleanup_addr, proglen, oldproglen = 0;
>>> -       u32 temp[8], *prog, *func, seen = 0, pass;
>>> -       const struct sock_filter *filter = fp->insns;
>>> -       int i, flen = fp->len, pc_ret0 = -1;
>>> +       unsigned int cleanup_addr, proglen, oldproglen;
>>> +       u32 temp[8], *prog, *func, seen, pass;
>>> +       const struct sock_filter *filter;
>>> +       int i, flen = fp->len, pc_ret0;
>>>         unsigned int *addrs;
>>>         void *image;
>>>
>>> @@ -385,6 +385,10 @@ void bpf_jit_compile(struct bpf_prog *fp)
>>>         }
>>>         cleanup_addr = proglen; /* epilogue address */
>>>         image = NULL;
>>> +       filter = fp->insns;
>>> +       oldproglen = 0;
>>> +       pc_ret0 = -1;
>>> +       seen = 0;
>>>         for (pass = 0; pass < 10; pass++) {
>>>                 u8 seen_or_pass0 = (pass == 0) ? (SEEN_XREG | SEEN_DATAREF | SEEN_MEM) : seen;
> …
>> If you were moving the assignments on declaration onto separate lines
>> at the top of the file then ok,
>
> I see another software design option where the transformation result might be looking
> more pleasing for you again.
>
>
>> but why all the way down here?
>
> * How do you think about the reason I gave in the short commit message?

Does this change improve the resulting binary? I.e. does it make it
smaller or faster? If it's smaller, by how much? if it's faster,
measure it.

Otherwise this change is useless churn - you're making the code more
complicated, longer and harder to read for practically no benefit.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@...il.com
Profile: http://www.google.com/profiles/julian.calaby/