netdev - Re: [patch 11/11] netfilter warning fix

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: <20070207080722.GC2434@elte.hu>
Date:	Wed, 7 Feb 2007 09:07:22 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, dipankar@...ibm.com, paulmck@...ibm.com
Subject: Re: [patch 11/11] netfilter warning fix

* Patrick McHardy <kaber@...sh.net> wrote:

> > this means that this particular use could be fixed by converting the 
> > preempt_disable()/enable() pair in nf_ct_l4proto_find_get() to 
> > rcu_read_lock()/unlock(), correct?
> 
> That is another bug (all uses of preempt_disable in netfilter 
> actually), but calling __nf_ct_l[34]proto_find without rcu_read_lock 
> is broken as well.
> 
> > Furthermore, every user of synchronize_net() [and synchronize_rcu() 
> > in general] needs to be reviewed.
> 
> I'll take care of netfilter.

great! Netfilter is one of the main users of synchronize_net() (about 
90% of the synchronize_net() callsites are in netfilter), and one of the 
main (well, in fact pretty much only) users of preempt_disable().

Dave, Patrick, can we lift the nack on PREEMPT_RCU, as far as networking 
goes? We really need some progress regarding it, and i think Paul is way 
too modest about pushing it. His patchset been in beta testing for like 
2 years meanwhile. PREEMPT_RCU has already found a nice set of 
bugs/uncleanlinesses elsewhere too, so even if you never actually enable 
PREEMPT_RCU (it's off by default), it's a nice generalization of the RCU 
framework that also tightens up its semantics. I think we need that, 
before existing code learns to depend on non-generic details of 
'classic' RCU too much. [my other interest in it, as you might have 
guessed, is that PREEMPT_RT depends on PREEMPT_RCU architecturally, but 
that shouldnt worry you - i think the upstream arguments alone are 
strong enough.]

	Ingo
-
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