On Tue, 30 Dec 2003 11:51:16 -0800
"Martin J. Bligh" <[email protected]> wrote:
> http://bugme.osdl.org/show_bug.cgi?id=1764
>
> Summary: conntrack oops while reading /proc/net/ip_conntrack
> Kernel Version: 2.6.0
> Status: NEW
> Severity: high
> Owner: [email protected]
> Submitter: [email protected]
...
> Apparently expect->expectant->helper is NULL in print_expect
> (net/ipv4/netfilter/ip_conntrack_standalone.c).
Um, Harald, other developers,
Shouldn't list_conntracks do READ_LOCK(&ip_conntrack_expect_tuple_lock) before walking the expect list?
Here's a patch. Does it do anything?
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
Name: Grab ip_conntrack_expect_tuple_lock in list_conntracks
Author: Rusty Russell
Status: Experimental
D: http://bugme.osdl.org/show_bug.cgi?id=1764
D: We're walking the expect list without the ip_conntrack_expect_tuple_lock.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .20891-linux-2.6.1-rc1/include/linux/netfilter_ipv4/ip_conntrack_core.h .20891-linux-2.6.1-rc1.updated/include/linux/netfilter_ipv4/ip_conntrack_core.h
--- .20891-linux-2.6.1-rc1/include/linux/netfilter_ipv4/ip_conntrack_core.h 2003-09-22 10:26:46.000000000 +1000
+++ .20891-linux-2.6.1-rc1.updated/include/linux/netfilter_ipv4/ip_conntrack_core.h 2004-01-03 15:27:14.000000000 +1100
@@ -50,5 +50,6 @@ static inline int ip_conntrack_confirm(s
extern struct list_head *ip_conntrack_hash;
extern struct list_head ip_conntrack_expect_list;
DECLARE_RWLOCK_EXTERN(ip_conntrack_lock);
+DECLARE_RWLOCK_EXTERN(ip_conntrack_expect_tuple_lock);
#endif /* _IP_CONNTRACK_CORE_H */
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .20891-linux-2.6.1-rc1/net/ipv4/netfilter/ip_conntrack_standalone.c .20891-linux-2.6.1-rc1.updated/net/ipv4/netfilter/ip_conntrack_standalone.c
--- .20891-linux-2.6.1-rc1/net/ipv4/netfilter/ip_conntrack_standalone.c 2003-12-18 15:53:34.000000000 +1100
+++ .20891-linux-2.6.1-rc1.updated/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-01-03 15:23:40.000000000 +1100
@@ -154,6 +154,7 @@ list_conntracks(char *buffer, char **sta
}
/* Now iterate through expecteds. */
+ READ_LOCK(&ip_conntrack_expect_tuple_lock);
list_for_each(e, &ip_conntrack_expect_list) {
unsigned int last_len;
struct ip_conntrack_expect *expect
@@ -164,10 +165,12 @@ list_conntracks(char *buffer, char **sta
len += print_expect(buffer + len, expect);
if (len > length) {
len = last_len;
- goto finished;
+ goto finished_expects;
}
}
+ finished_expects:
+ READ_UNLOCK(&ip_conntrack_expect_tuple_lock);
finished:
READ_UNLOCK(&ip_conntrack_lock);
On Sat, Jan 03, 2004 at 03:29:21PM +1100, Rusty Russell wrote:
> Um, Harald, other developers,
>
> Shouldn't list_conntracks do
> READ_LOCK(&ip_conntrack_expect_tuple_lock) before walking the
> expect list?
Thanks Rusty, indeed it should.
> Here's a patch. Does it do anything?
To the bug reporter(s): Please give feedback on that patch.
> Rusty.
--
- Harald Welte <[email protected]> http://www.netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
Am Sa, den 03.01.2004 schrieb Rusty Russell um 05:29:
> > http://bugme.osdl.org/show_bug.cgi?id=1764
> >
> > Summary: conntrack oops while reading /proc/net/ip_conntrack
> > Kernel Version: 2.6.0
> > Status: NEW
> > Severity: high
> > Owner: [email protected]
> > Submitter: [email protected]
> ...
> > Apparently expect->expectant->helper is NULL in print_expect
> > (net/ipv4/netfilter/ip_conntrack_standalone.c).
>
> Um, Harald, other developers,
>
> Shouldn't list_conntracks do READ_LOCK(&ip_conntrack_expect_tuple_lock) before walking the expect list?
>
> Here's a patch. Does it do anything?
The problem seems to fixed. The machine was stable the last week, before
it crashed at least once a day.
thanks.