Re: [PATCH] update raw patch in POM [2.4.x]

[Patrick McHardy <kaber@trash.net>]

Roberto Nibali wrote:
>>Pablo mentioned to me in private mail that he believes the reason
>>is packets holding references to ip_conntrack_untracked on module
>>removal. I agree, and this patch should fix it. Roberto, could
>>you please try it and tell me if it helps?
> 
> 
> I already did. Here's an excerpt of an earlier email in this thread regarding
> this patch:

Hmmm I should have read the whole thread :)

>>--- linux-2.4.orig/net/ipv4/netfilter/ip_conntrack_core.c	2005-06-15
>>
>>>23:16:43.000000000 +0200
>>>+++ linux-2.4/net/ipv4/netfilter/ip_conntrack_core.c	2005-06-17
>>>20:44:18.000000000 +0200
>>>@@ -1391,6 +1391,8 @@
>>> 		schedule();
>>> 		goto i_see_dead_people;
>>> 	}
>>>+	while (atomic_read(&ip_conntrack_untracked.ct_general.use) != 1)
>>>+		schedule();
>>>
>>> 	kmem_cache_destroy(ip_conntrack_cachep);
>>> 	vfree(ip_conntrack_hash);
> 
> 
> 
> This results in an endless loop when calling rmmod ip_conntrack. lsmod shows
> (deleted) but the process is in D state. No oops of course and no hang.
> 
> But I cannot remove the ip_conntrack kernel module anymore. It's "stuck".

This means we're either leaking conntrack entries or packets holding
a reference are queued somewhere. What do you use NOTRACK for?

> Do you want me to rerun the test for more precise statements?

Yes, please make sure no packets are queued in qdiscs (best to use
pfifo) and no raw/packet sockets are open and ip_queue isn't used.
You could also add a printk to the inner body of the
while(atomic_read(...)) loop and print out the reference count, perhaps
it will show something interesting.

Thanks
Patrick