Is this death_by_timeout's bug???

["kendo" <kendo999@xxxxxxxx>]

netfilter-devel:

	Hi!
    
In my linux 2.6.30.9，I found a strange question about netfilter：
 
[root@localhost ~]# conntrack -L | grep flow
conntrack v0.9.13 (conntrack-tools): 321 flow entries have been shown.

[root@localhost ~]# conntrack -C
14360

ct.count(14360) is far greater than the conntrack hash table number(321). Final，table full……game over.

Further analysis of statistics counters：

[root@localhost ~]# cat /proc/net/stat/nf_conntrack
entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete
0000392c  00000078 00036049 000042b9 000005f7 0000037f 00000468 000039af 00004291 0000002a 00000000 00000000 0000015c  00000000 00000000 00000000 
0000392c  00000003 0000873e 00000012 00000061 00000414 00000053 000007a5 00000012 00000000 00000000 00000000 00000002  00000000 00000000 00000000 
0000392c  00000000 000017c4 00000002 00000012 00000eb8 00000103 00000009 00000002 00000000 00000000 00000000 00000000  00000000 00000000 00000000 
0000392c  00000004 00002a4d 00000004 00000018 000005a3 000000f6 00000011 00000003 00000000 00000000 00000000 00000003  00000000 00000000 00000000 
0000392c  00000006 000034d6 0000007d 0000004f 00000197 000000a5 00000031 00000030 00000051 00000000 00000000 0000000c  00000000 00000000 00000000 
0000392c  00000004 000038a8 00000004 00000055 00000383 000000cf 00000016 00000004 00000000 00000000 00000000 00000002  00000000 00000000 00000000 
0000392c  00000004 00002e82 00000004 0000000d 0000179c 0000010e 00000014 00000004 00000000 00000000 00000000 00000000  00000000 00000000 00000000 
0000392c  00000001 00003911 00000005 0000006d 000002fd 000000f9 00000011 00000005 00000000 00000000 00000000 00000002  00000000 00000000 00000000

I found "delete_list"(16868) countres is far greater than the "delete"(2607) counters.Is cant't be release when a conntrack be delete from conntrack hash table？？？

static void death_by_timeout(unsigned long ul_conntrack)
{
 struct ip_conntrack *ct = (void *)ul_conntrack;

 WRITE_LOCK(&ip_conntrack_lock);
 /* Inside lock so preempt is disabled on module removal path.
  * Otherwise we can get spurious warnings. */
 CONNTRACK_STAT_INC(delete_list);
 clean_from_lists(ct);
 WRITE_UNLOCK(&ip_conntrack_lock);
 ip_conntrack_put(ct);
}

static inline void nf_conntrack_put(struct nf_conntrack *nfct)
{
 if (nfct && atomic_dec_and_test(&nfct->use))
  nf_conntrack_destroy(nfct);
}

What is wrong with the nfct->use counter may be the problem, Lead to nf_conntrack_destroy functions can not properly be called? From a statistical counter to the results of,clean_from_lists have been implemented, but the nf_conntrack_destroy does not seem to be running.

This is only my guess，I didn't fond any thing from the source code.However, if it is not so，What causes my connection to track the total number of non-stop to rise，table full and memory has been eaten？？

Thanks, Hope to get your help!

Environment：
---------internet--cisco switch (two port bonding)-------linux box(two bridge)-------cisco switch(two port bonging)-----server

Cisco switch link aggregation，use two port。Linux box have two Independent network bridge。

 				

　　　　　　　　kendo
　　　　　　　　kendo999@xxxxxxxx
　　　　　　　　　　2009-11-23
��.n��������+%������w��{.n����z��׫���n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m