On Sun, 2007-02-25 at 18:31 +0100, Patrick McHardy wrote: > [NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops > > {nf,ip}_ct_iterate_cleanup iterate over the unconfirmed list for cleaning > up conntrack entries, which is wrong for multiple reasons: > > - unconfirmed entries can not be killed manually, which means we might > iterate forever without making forward progress. > > This can happen in combination with the conntrack event cache, which > holds a reference to the conntrack entry, which is only released when > the packet makes it all the way through the stack or a different > packet is handled. > > - taking references to an unconfirmed entry and using it outside the > locked section doesn't work, the list entries are not refcounted and > another CPU might already be waiting to destroy the entry > > Split ip_ct_iterate_cleanup in ip_ct_iterate, which iterates over both > confirmed and unconfirmed entries, but doesn't attempt to kill them, > and ip_ct_cleanup, which makes sure no unconfirmed entries exist by > calling synchronize_net() prior to walking the conntrack hash. What about this case: 1. Conntrack entry is created and placed on the unconfirmed list 2. The event cache bumps the refcount of the conntrack entry 3. module removal of ip_conntrack unregisters all hooks 4. packet is dropped by an iptables rule 5. packet is freed but we still have a refcount on the conntrack entry Now there's no way to get that refcount to decrease as that only happens when the event cache receives another packet or the current packet makes it through the stack as you wrote above. And neither of this will happen since we unregistered the hooks providing the packets and dropped the packet. I ran into this case a while ago during stresstesting and rewrote the event cache to not increase the refcount, but this has the drawback that events caused by dropped packets won't be reported. This may not be a good thing... Old patch can be found here: http://performance.netfilter.org/patches/nf_conntrack_ecache-fix -- /Martin
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Patrick McHardy <[email protected]>
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- References:
- Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Chuck Ebbert <[email protected]>
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Chuck Ebbert <[email protected]>
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Patrick McHardy <[email protected]>
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Chuck Ebbert <[email protected]>
- Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- From: Patrick McHardy <[email protected]>
- Soft lockup on shutdown in nf_ct_iterate_cleanup()
- Prev by Date: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Next by Date: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Previous by thread: Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- Next by thread: Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
- Index(es):