Patrick McHardy wrote:
> Thanks, the previous approach doesn't seem to work properly without
> unpleasant event cache hacks. This patch takes a simpler approach
> and keeps the unconfirmed list iteration, but makes sure to make
> forward progress.
>
>
>
>
Chuck Ebbert wrote:
> Patrick McHardy wrote:
>
>>This patch is against current stable-2.6.20, it applies
>>cleanly to 2.6.20 as well.
>
>
> Everything works OK, but I get:
>
> BUG: warning: (!list_empty(&unconfirmed)) at
> net/netfilter/nf_conntrack_core.c:1068/nf_ct_cleanup()
>
> <> nf_ct_clean
Patrick McHardy wrote:
> This patch is against current stable-2.6.20, it applies
> cleanly to 2.6.20 as well.
>
Everything works OK, but I get:
BUG: warning: (!list_empty(&unconfirmed)) at
net/netfilter/nf_conntrack_core.c:1068/nf_ct_cleanup()
<> nf_ct_cleanup+0x66/0x122 [nf_conntrack]
<> kill_
Chuck Ebbert wrote:
> Changes to nf_nat_core.c, ip_nat_core.c and nf_conntrack_proto.c
> do not apply, and nf_conntrack_core.c changes are already there.
>
> This is vanilla 2.6.20; looks like there have been a bunch
> of changes since then. I tried adding all of the RCU patches
> but even they w
Patrick McHardy wrote:
> Chuck Ebbert wrote:
>
> Can you try this patch please?
>
>
> [NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
>
> include/linux/netfilter_ipv4/ip_conntrack.h |5 ++--
> in
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 ca
Martin Josefsson wrote:
> 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 fr
Chuck Ebbert wrote:
> It is the standard Fedora script "iptables" and it recursively
> unloads all referring modules, then the base ones: ip_tables and
> ip_conntrack. I can't tell which module it stopped on because
> that computer is at home today.
>
> And yes, it really locks up until it's caug
Chuck Ebbert wrote:
> Chuck Ebbert wrote:
>
>>I was testing a 2.6.20 kernel and got a soft
>>lockup on shutdown:
>>
>>_raw_write_lock+0x5a
>>nf_ct_iterate_cleanup+0x3e
>>kill_l3proto+0x0
>>nf_conntrack_l3proto_unregister+0x85
>>nf_conntrack_l3proto_ipv4_fini+0x1e
>>sys_delete_module+0x18a
>>remove
Chuck Ebbert wrote:
> I was testing a 2.6.20 kernel and got a soft
> lockup on shutdown:
>
> _raw_write_lock+0x5a
> nf_ct_iterate_cleanup+0x3e
> kill_l3proto+0x0
> nf_conntrack_l3proto_unregister+0x85
> nf_conntrack_l3proto_ipv4_fini+0x1e
> sys_delete_module+0x18a
> remove_vma+0x45
> do_munmap+0x1
I was testing a 2.6.20 kernel and got a soft
lockup on shutdown:
_raw_write_lock+0x5a
nf_ct_iterate_cleanup+0x3e
kill_l3proto+0x0
nf_conntrack_l3proto_unregister+0x85
nf_conntrack_l3proto_ipv4_fini+0x1e
sys_delete_module+0x18a
remove_vma+0x45
do_munmap+0x196
syscall_call+0x7
-
To unsubscribe fro
11 matches
Mail list logo
