Jan Engelhardt wrote:
On Wednesday 2008-09-24 12:01, Patrick McHardy wrote:
@@ -545,6 +545,7 @@ ctnetlink_dump_table(struct sk_buff *skb, struct
netlink_callback *cb)
u_int8_t l3proto = nfmsg->nfgen_family;
rcu_read_lock();
+ spin_lock_bh(&nf_conntrack_lock);
We only need the spinlock. I'm not so happy about taking it
unconditionally even though we might not be zeroing the
counters. Moving it in the inner loop will greatly increase
the amount of locks/unlocks on the other hand.
How about moving the inner loop to a new function and adding
back the ctnetlink_dump_counterzero (or whatever it was called)
function? It would take the spinlock, while normal dumping
would only use rcu_read_lock().
Perhaps this might work?
+ if (cb->args[0] >= nf_conntrack_htable_size) {
+ nf_ct_put(cb->args[1]);
+ return skb->len;
+ }
I'm not sure what you're trying to fix here. Its a race
between counter zeroing and changing them during packet
processing. Any patch that doesn't include a spin_lock
can't really fix the problem :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
