netdev - Re: [PATCH net-next-2.6] filter: optimize sk_run

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: <1290185759.3034.179.camel@edumazet-laptop>
Date:	Fri, 19 Nov 2010 17:55:59 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	hagen@...u.net, netdev@...r.kernel.org, xiaosuo@...il.com
Subject: Re: [PATCH net-next-2.6] filter: optimize sk_run_filter

Le vendredi 19 novembre 2010 à 08:21 -0800, David Miller a écrit :

> -EFIX_THE_DAMN_COMPILER
> 
> We never make calls out of this function or touch volatile memory or
> create a full memory barrier between the assignment of f_k and it's
> uses.
> 
> Therefore if common sub-expression elimination is working the compiler
> will be able to decide properly whether to access things via memory or
> use a register for the value.
> 
> Remember this is why we have that ACCESS_ONCE() thing.
> 
> We can't have it both ways, either ACCESS_ONCE() should be removed or
> we should never make changes like your's and instead should submit
> compiler bug reports :-)

Compiler is OK IMHO in this case. It does exactly what is required.

Compiler cannot load fentry->k before the switch() if some expression
dont use it, as it could trigger a fault.

After the "f_k = fentry->k;" commit, it was requested to do so.

Unfortunatly on x86_32 it also chose that f_k was more valuable in a cpu
register and accumulator A lost its register to get a stack slot
instead.

Not many BPF instructions use K, and if used, its used _once_ per BPF
instruction. There is no real gain to put it on a register, but code
size if (and only if) it is held in a cpu register, because each
assembler instruction using a register instead of stack is a bit
shorter.

In the end, I believe the "f_k = fentry->k;" was a good looking idea,
and good for some arches, but we forgot x86_32 (and probably some others)
have few available registers to play with.

Have a good week end !

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html