Messages in this thread | | | Date | Wed, 17 Jun 2009 15:27:28 +0200 | From | Eric Dumazet <> | Subject | Re: [bug] __nf_ct_refresh_acct(): WARNING: at lib/list_debug.c:30 __list_add+0x7d/0xad() |
| |
Patrick McHardy a écrit : > Eric Dumazet wrote: >> Patrick McHardy a écrit : >>> Eric Dumazet wrote: >>>> Patrick McHardy a écrit : >>>>> Before the conntrack is confirmed, it is exclusively handled by a >>>>> single CPU. I agree that we need to make sure the IPS_CONFIRMED_BIT >>>>> is visible before we add the conntrack to the hash table since the >>>>> lookup is lockless, but simply moving the set_bit before the hash >>>>> insertion should be fine I think. >>>>> >>>> >>>> Problem is timeout.expires is either a relative or absolute timeout, >>>> and changes happen >>>> in __nf_conntrack_confirm() or __nf_ct_refresh_acct(). >>>> >>>> We must have a synchronization (an barriers), a single bit wont be >>>> enough. >>> Please have a look at the second patch I just sent. It relies >>> on the RCU barriers to make sure all stores are visible before >>> other CPUs can find the conntrack. >>> >> >> Sorry, I dont understand how your second patch corrects the problem. >> >> This (unconfirmed) conntrack is visible by another cpu. > > No, before it is confirmed, its only visible to the CPU handling > the initial packet of a connection. Confirmation is the step that > makes it visible to other CPUs.
Thanks Patrick, I missed this, and your patch seems fine now :)
> >> This other >> cpu can call __nf_ct_refresh_acct() while this cpu runs >> in __nf_conntrack_confirm() > > Not for the same conntrack, that would be a seperate bug. > > Does that explain what I'm trying to do? :)
Yes sure, thanks again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |