* Patrick McHardy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
