Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > What should have been initialized it? nf_ct_refresh_acct() > I assume it should have been happened in between init_conntrack and > nf_conntrack_confirm, because nf_conntrack_confirm already adds to an > uninit timeout value. Yes. > Since we got only 3 such reports and no reproducer, I would suspect > that there is some race involved. Is it possible that timeout > initialization (presumably a call to nf_ct_refresh_acct) happens after > and non-atomically with the corresponding connection state update, so > that the call to nf_conntrack_confirm sneaks before it? Unconfirmed conntrack isn't in the hash table, so all events should occur in order on same cpu: 1. allocation (init_conntrack) 2. timeout initialisation (via l4 tracker, can be generic one too) 3. nf_conntrack_confirm (insertion in hash table) What could be possible is that another core is registering/unregistering the conntrack hooks in parallel, I guess in that case we could have: 1. allocation (init_conntrack) (other cpu: remove conntrack hooks) (other cpu: add conntrack hooks) 3. nf_conntrack_confirm (insertion in hash table) Just a theory of course. In any case patch looks good to me. -- 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
