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: <20101119.095200.59681766.davem@davemloft.net>
Date:	Fri, 19 Nov 2010 09:52:00 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	xiaosuo@...il.com
Cc:	eric.dumazet@...il.com, hagen@...u.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next-2.6 v2] filter: optimize sk_run_filter

From: Changli Gao <xiaosuo@...il.com>
Date: Fri, 19 Nov 2010 22:13:07 +0800

> On Fri, Nov 19, 2010 at 9:16 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>> [PATCH net-next-2.6 v2] filter: optimize sk_run_filter
>>
>> Remove pc variable to avoid arithmetic to compute fentry at each filter
>> instruction. Jumps directly manipulate fentry pointer.
>>
>> As the last instruction of filter[] is guaranteed to be a RETURN, and
>> all jumps are before the last instruction, we dont need to check filter
>> bounds (number of instructions in filter array) at each iteration, so we
>> remove it from sk_run_filter() params.
>>
>> On x86_32 remove f_k var introduced in commit 57fe93b374a6b871
>> (filter: make sure filters dont read uninitialized memory)
>>
>> Note : We could use a CONFIG_ARCH_HAS_{FEW|MANY}_REGISTERS in order to
>> avoid too many ifdefs in this code.
>>
>> This helps compiler to use cpu registers to hold fentry and A
>> accumulator.
>>
>> On x86_32, this saves 401 bytes, and more important, sk_run_filter()
>> runs much faster because less register pressure (One less conditional
>> branch per BPF instruction)
>>
>> # size net/core/filter.o net/core/filter_pre.o
>>   text    data     bss     dec     hex filename
>>   2948       0       0    2948     b84 net/core/filter.o
>>   3349       0       0    3349     d15 net/core/filter_pre.o
>>
>> on x86_64 :
>> # size net/core/filter.o net/core/filter_pre.o
>>   text    data     bss     dec     hex filename
>>   5173       0       0    5173    1435 net/core/filter.o
>>   5224       0       0    5224    1468 net/core/filter_pre.o
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
>> Cc: Changli Gao <xiaosuo@...il.com>
>> Cc: Hagen Paul Pfeifer <hagen@...u.net>
> 
> Acked-by: Changli Gao <xiaosuo@...il.com>

Ok, I'm applying this to net-next-2.6 for now.  It keeps the
"f_k" situation optimal for all cases, on every platform I've
taken a look at the asm output (sparc64, x86-32, x86-64).

I can't currently think of a way to get rid of that ifdef,
so for now it's a small price to pay to get this optimal.

Thanks Eric!
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ