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: <20250820160114.LI90UJWx@linutronix.de>
Date: Wed, 20 Aug 2025 18:01:14 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Stefano Brivio <sbrivio@...hat.com>
Cc: Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, netfilter-devel@...r.kernel.org,
	pablo@...filter.org
Subject: Re: [PATCH net-next 5/6] netfilter: nft_set_pipapo: Store real
 pointer, adjust later.

On 2025-08-20 17:44:01 [+0200], Stefano Brivio wrote:
> On Wed, 20 Aug 2025 16:47:37 +0200
> Florian Westphal <fw@...len.de> wrote:
> 
> > From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> > 
> > The struct nft_pipapo_scratch is allocated, then aligned to the required
> > alignment and difference (in bytes) is then saved in align_off. The
> > aligned pointer is used later.
> > While this works, it gets complicated with all the extra checks if
> > all member before map are larger than the required alignment.
> > 
> > Instead of saving the aligned pointer, just save the returned pointer
> > and align the map pointer in nft_pipapo_lookup() before using it. The
> > alignment later on shouldn't be that expensive.
> 
> The cost of doing the alignment later was the very reason why I added
> this whole dance in the first place though. Did you check packet
> matching rates before and after this?

how? There was something under selftest which I used to ensure it still
works.
On x86 it should be two additional opcodes (and + lea) and that might be
interleaved. Do you remember a rule of thumb of your improvement?
As far as I remember the alignment code expects that the "hole" at the
begin does not exceed a certain size and the lock there exceeds it.

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ