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()) at
> net/netfilter/nf_conntrack_core.c:1068/nf_ct_cleanup()
>
> <>
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_cleanup+0x66/0x122
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.
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()) at
net/netfilter/nf_conntrack_core.c:1068/nf_ct_cleanup()
<> nf_ct_cleanup+0x66/0x122 [nf_conntrack]
<> kill_l4proto+0x0
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
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 ++--
>
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 ++--
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 won't
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]
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
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
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
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 caught by
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 freed
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
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
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_vma+0x45
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
>
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+0x196
20 matches
Mail list logo
