2.4.23/others and ip_conntrack causing hangs

2.4.23/others and ip_conntrack causing hangs

[James Bourne]

Hi all,
I wanted to bring up an issue with ip_conntrack in 2.4.23, 2.4.22, and at
least 2.4.21 (sorry, didn't try 2.4.20).

The issue is that as long as there are connections being tracked, the
ip_conntrack module will not unload.  I can understand why this might be,
but the problem is that ip_conntrack will hang rmmod and modprobe -r until
such time as all the connections have been closed.

I think we need something like an ip_conntrack_flush or else completely drop
the connections when the module is unloaded (as previously done) as this
becomes an issue for people who need to drop their ip_tables and reload the
modules (perhaps to correct other issues) especially ip_conntrack...  

The only way to reload the modules right now (yes, I know removing modules
from a running kernel is dodgey anyway) is to completely drop the network
interfaces which kills off the connections *anyway*.  So, dropping the
connections shouldn't be an issue.

Thanks for the consideration.

Regards
James

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert  

Re: [netfilter-core] 2.4.23/others and ip_conntrack causing hangs

[Rusty Russell]

In message <Pine.LNX.4.44.0311301204520.2148-100000@cafe.hardrock.org> you writ
e:
> Hi all,
> I wanted to bring up an issue with ip_conntrack in 2.4.23, 2.4.22, and at
> least 2.4.21 (sorry, didn't try 2.4.20).
> 
> The issue is that as long as there are connections being tracked, the
> ip_conntrack module will not unload.  I can understand why this might be,
> but the problem is that ip_conntrack will hang rmmod and modprobe -r until
> such time as all the connections have been closed.
> 
> I think we need something like an ip_conntrack_flush or else completely drop
> the connections when the module is unloaded (as previously done) as this
> becomes an issue for people who need to drop their ip_tables and reload the
> modules (perhaps to correct other issues) especially ip_conntrack...  

Um, this is exactly what the code does on unload: an explicit flush.

Unfortunately, some packets are still referencing connections, so the
module *cannot* go away.  Figuring out exactly where the packets are
referenced from is the fun part.  We explicitly drop the reference in
ip_local_deliver_finish() for exactly this reason.  Perhaps there is
somewhere else we should be doing the same thing.

Hope that clarifies,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [netfilter-core] 2.4.23/others and ip_conntrack causing hangs

[Patrick McHardy]

Rusty Russell wrote:

>Unfortunately, some packets are still referencing connections, so the
>module *cannot* go away.  Figuring out exactly where the packets are
>referenced from is the fun part.  We explicitly drop the reference in
>ip_local_deliver_finish() for exactly this reason.  Perhaps there is
>somewhere else we should be doing the same thing.
>  
>
Perhaps in dev_queue_xmit ? Otherwise packets stuck in queues hold
references to conntracks. Loopback traffic might cause some trouble
because the "previously seen?" expection in ip_conntrack_core wouldn't
work anymore.

Best regards,
Patrick

>Hope that clarifies,
>Rusty.
>--
>  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>-
>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/
>  
>

Re: [netfilter-core] 2.4.23/others and ip_conntrack causing hangs

[Rusty Russell]

In message <3FCBDABF.6080804@trash.net> you write:
> Rusty Russell wrote:
> 
> >Unfortunately, some packets are still referencing connections, so the
> >module *cannot* go away.  Figuring out exactly where the packets are
> >referenced from is the fun part.  We explicitly drop the reference in
> >ip_local_deliver_finish() for exactly this reason.  Perhaps there is
> >somewhere else we should be doing the same thing.
> >  
> >
> Perhaps in dev_queue_xmit ? Otherwise packets stuck in queues hold
> references to conntracks. Loopback traffic might cause some trouble
> because the "previously seen?" expection in ip_conntrack_core wouldn't
> work anymore.

But I wouldn't expect packets there to be held indefinitely, so I
never worried about it.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [netfilter-core] 2.4.23/others and ip_conntrack causing hangs

[Patrick McHardy]

Rusty Russell wrote:

>>Perhaps in dev_queue_xmit ? Otherwise packets stuck in queues hold
>>references to conntracks. Loopback traffic might cause some trouble
>>because the "previously seen?" expection in ip_conntrack_core wouldn't
>>work anymore.
>>    
>>
>
>But I wouldn't expect packets there to be held indefinitely, so I
>never worried about it.
>  
>

A prio qdisc for example can hold packets indefinitely as long as a higher
prio flow is active. I actually experienced problems unloading ip_conntrack
while playing with qdiscs until I removed the qdisc, but I hacked some stuff
before so it could be my own fault (and sometimes removing the qdisc didn't
help either). Anyways, it may be a corner case but I'm pretty sure there are
no lost references in ip_conntrack itself so maybe some of the sporadic
reports of hanging unload could be explained by this. I'm going to do some
more testing and then we can see.

Best regards,
Patrick