linux-kernel - Re: [PATCH] netfilter: use per-cpu spinlock rather than RCU (v3)

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: <alpine.LFD.2.00.0904171028070.4042@localhost.localdomain>
Date:	Fri, 17 Apr 2009 10:32:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	David Miller <davem@...emloft.net>, paulmck@...ux.vnet.ibm.com,
	dada1@...mosbay.com, shemminger@...tta.com, kaber@...sh.net,
	jeff.chua.linux@...il.com, paulus@...ba.org, mingo@...e.hu,
	laijs@...fujitsu.com, jengelh@...ozas.de, r000n@...0n.net,
	linux-kernel@...r.kernel.org, netfilter-devel@...r.kernel.org,
	netdev@...r.kernel.org, benh@...nel.crashing.org,
	mathieu.desnoyers@...ymtl.ca
Subject: Re: [PATCH] netfilter: use per-cpu spinlock rather than RCU (v3)

On Fri, 17 Apr 2009, Peter Zijlstra wrote:
> 
> Since its a full broadcast, we can do that _today_ using on_each_cpu().
> But whatever way we turn this, this will be a very expensive operation.
> Imagine doing that on your 256-way for every iptables rules change.

Well, you _could_ just have a per-CPU bit of "have I used nf rules since 
the last update", and skip those CPU's. Use memory ordering to check the 
bits (set the bit _before_ looking up a NF rule, and check them _after_ 
doing the update, and have a barrier in between if you really think it 
matters).

Remember: the cost was never about a single filter rule update. The cost 
of a single one is almost immaterial, as long as it's not in hundreds of 
milliseconds. It's the cost of people building up things incrementally 
that caused this thing.

So if you have 200 "iptables" commands in a sequence, and especially 
during bootup, a trivial "has the old rule been ever even looked at on 
this CPU" would already fix the issue. Because it would always be zero in 
the only case where it matters.

This is, of course, what we do for the TLB flushing issue. We don't want 
to send IPI's to all CPU's, and in 99.999% of all cases we don't need to, 
because the other CPU's never even loaded the MM.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/