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

[Roberto Nibali <ratz@tac.ch>]

Hello Patrick,

Thanks for looking into this. I've added a 2.4.x into the subject because it
seems people forget it sometimes :)

>>>If the module gets unloaded, ip_conntrack_untracked refcount isn't 
>>>decreased, it's still 1. So destroy() is never called. In that case it 
>>>should be really easy to trigger on my slow laptop ;->.
>>
>>How do you explain the BUG() being triggered then?
> 
> 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:

>--- 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".

> diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
> --- a/net/ipv4/netfilter/ip_conntrack_core.c
> +++ b/net/ipv4/netfilter/ip_conntrack_core.c
> @@ -1111,7 +1111,9 @@ void ip_conntrack_cleanup(void)
>  		schedule();
>  		goto i_see_dead_people;
>  	}
> -
> +	/* wait until all references to ip_conntrack_untracked are dropped */
> +	while (atomic_read(&ip_conntrack_untracked.ct_general.use) > 1)
> +		schedule();
>  	kmem_cache_destroy(ip_conntrack_cachep);
>  	kmem_cache_destroy(ip_conntrack_expect_cachep);
>  	free_conntrack_hash();

This is not a pristine 2.4.x kernel source you diffed against, rather a 2.6.x
one. The ip_conntrack_expect_cachep kmem cache was not used in 2.4.x AFAIK.

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

Best regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------