The warning below started showing up on kerneloops.org in the top 20 and it appears to
be new in 2.6.27-rc (e.g. a regression)...It happens when nf_conntrack is rmmod'd
The reports:
http://www.kerneloops.org/search.php?search=nf_conntrack_acct_finiThe warning:
WARNING: at kernel/sysctl.c:1966 unregister_sysctl_table+0xcc/0x103()
Modules : nf_conntrack(-)
Call Trace:
[<ffffffff81043bc8>] warn_on_slowpath+0x65/0x98
[<ffffffff8104abdf>] unregister_sysctl_table+0xcc/0x103
[<ffffffffa0306655>] nf_conntrack_acct_fini+0x15/0x23 [nf_conntrack]
[<ffffffffa03018a1>] nf_conntrack_cleanup+0x84/0x86 [nf_conntrack]
[<ffffffffa0306944>] nf_conntrack_standalone_fini+0x40/0x42 [nf_conntrack]
[<ffffffff810700d0>] sys_delete_module+0x202/0x263
[<ffffffff8101034a>] system_call_fastpath+0x16/0x1b--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
Thanks. It seems I'm the person who introduced it. I'll look at it ASAP.
Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
Probably spoken too fast. This problem was introduced in 2.6.26-git15,=20
about one week after my accounting rework had been included. Obviously=20
there is something wrong with netfilter sysctl handling as starting with=20
this kernel version sysctl reports duplicated net.netfilter:# find /proc/sys/net/|grep net/netf
/proc/sys/net/netfilter
/proc/sys/net/netfilter/nf_conntrack_generic_timeout
/proc/sys/net/netfilter/nf_conntrack_acct
/proc/sys/net/netfilter
/proc/sys/net/netfilter/nf_conntrack_generic_timeout
/proc/sys/net/netfilter/nf_conntrack_acct# sysctl -a|grep net.netfilter
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1Still investigating.
Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
BTW: It also happens when I revert my patch:
sysctl -a|grep net.netfilter
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_generic_timeout =3D 600Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
And the winner is... 9043476f726802f4b00c96d0c4f418dde48d1304:
[PATCH] sanitize proc_sysctl
* keep references to ctl_table_head and ctl_table in /proc/sys inodes
* grab the former during operations, use the latter for access to
entry if that succeeds
* have ->d_compare() check if table should be seen for one who does lookup;
that allows us to avoid flipping inodes - if we have the same name resol=
ve
to different things, we'll just keep several dentries and ->d_compare()
will reject the wrong ones.
* have ->lookup() and ->readdir() scan the table of our inode first, then
walk all ctl_table_header and scan ->attached_by for those that are
attached to our directory.
* implement ->getattr().
* get rid of insane amounts of tree-walking
* get rid of the need to know dentry in ->permission() and of the contortio=
ns
induced by that.Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
With this patch "sysctl -a|grep net.netfilter" shows only=20
net.netfilter.nf_conntrack_generic_timeout and=20
net.netfilter.nf_conntrack_acct, both are duplicate btw:# sysctl -a 2>/dev/null|grep netf
net.ipv4.netfilter.ip_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1Without that commit I get full sysctl tree:
# sysctl -a 2>/dev/null|grep netf
net.ipv4.netfilter.ip_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1
net.netfilter.nf_conntrack_max =3D 32768
net.netfilter.nf_conntrack_count =3D 0
net.netfilter.nf_conntrack_buckets =3D 8192
net.netfilter.nf_conntrack_checksum =3D 1
net.netfilter.nf_conntrack_log_invalid =3D 0
net.netfilter.nf_conntrack_expect_max =3D 128And of course no WARNING at unloading as it comes from that patch=20
directly:- for (i =3D 1; table && (i <...
Almost definitely problems with registration order ;-/ I'll look into
that once I get a bit of sleep...
--
... and registration order it is. Try adding
static struct ctl_table empty[1];
register_sysctl_paths(nf_net_netfilter_sysctl_path, empty);
in netfilter_init() and see if that solves the problem.
--
Solves partially: no more WARNING, however entries are still=20
missing & duplicated:# sysctl -a 2>/dev/null|grep net.netfilter
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1
net.netfilter.nf_conntrack_generic_timeout =3D 600
net.netfilter.nf_conntrack_acct =3D 1Plus, without nf_conntrack module loaded I get empty=20
/proc/sys/net/netfilter/, but this is probably expected.--- a/net/netfilter/core.c 2008-07-13 23:51:29.000000000 +0200
+++ b/net/netfilter/core.c 2008-08-04 22:56:42.000000000 +0200
@@ -26,6 +26,10 @@static DEFINE_MUTEX(afinfo_mutex);
+#ifdef CONFIG_SYSCTL
+ static struct ctl_table empty[1];
+#endif
+
const struct nf_afinfo *nf_afinfo[NPROTO] __read_mostly;
EXPORT_SYMBOL(nf_afinfo);@@ -275,6 +279,10 @@
panic("cannot create netfilter proc entry");
#endif+#ifdef CONFIG_SYSCTL
+ register_sysctl_paths(nf_net_netfilter_sysctl_path, empty);
+#endif
+
if (netfilter_queue_init() < 0)
panic("cannot initialize nf_queue");
if (netfilter_log_init() < 0)Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
Very interesting. Could you see at which point duplicates appear? I.e.
in which sequence do you get registrations, at least on the level of "this
module is loaded first, no duplicates, this one comes after, etc."... ah, hell. I see what's going on. The trouble is in
nf_conntrack_standalone; you get a table that has _both_ net.netfilter.* and
net.nf_conntrack_max, which means that it's attached to unified tree at
net; if we already have something with net.netfilter, you've got trouble -
which entry net.netfilter will come from?_All_ this crap comes from lousy historical API; it's too much for this
cycle, but for .28 I'm going to clean that mess up. For now, split that
table in two and register them separately. I.e. register nf_ct_sysctl_table[]
at nf_net_netfilter_sysctl_path *and* remove the "netfilter" entry from
nf_ct_netfilter_table[].I'm really going down right now; will follow up after I get some sleep...
--
Right. I'll try to prepare and test your ideas at that time. Thank you=20
again.Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
ain.
Both good and bad news. The good one is with two above fixes the netfilter=
=20
issue seems to be now solved. However, starting from the
9043476f726802f4b00c96d0c4f418dde48d1304, even with NETFILNER=3Dn, there ar=
e=20
other duplicated entries:# find /proc/sys -type d |sort|uniq -d
/proc/sys/net/core
/proc/sys/net/ipv4/route
/proc/sys/net/ipv6
/proc/sys/net/ipv6/conf
/proc/sys/net/ipv6/conf/all
/proc/sys/net/ipv6/conf/bond0
/proc/sys/net/ipv6/conf/default
/proc/sys/net/ipv6/conf/dummy0
/proc/sys/net/ipv6/conf/eth0
/proc/sys/net/ipv6/conf/eth1
/proc/sys/net/ipv6/conf/eth2
/proc/sys/net/ipv6/conf/gre0
/proc/sys/net/ipv6/conf/ip6tnl0
/proc/sys/net/ipv6/conf/lo
/proc/sys/net/ipv6/conf/sit0
/proc/sys/net/ipv6/conf/tunl0
/proc/sys/net/ipv6/conf/vlan1
/proc/sys/net/ipv6/conf/vlan33
/proc/sys/net/ipv6/icmp
/proc/sys/net/ipv6/neigh
/proc/sys/net/ipv6/neigh/bond0
/proc/sys/net/ipv6/neigh/default
/proc/sys/net/ipv6/neigh/dummy0
/proc/sys/net/ipv6/neigh/eth0
/proc/sys/net/ipv6/neigh/eth1
/proc/sys/net/ipv6/neigh/eth2
/proc/sys/net/ipv6/neigh/gre0
/proc/sys/net/ipv6/neigh/ip6tnl0
/proc/sys/net/ipv6/neigh/lo
/proc/sys/net/ipv6/neigh/sit0
/proc/sys/net/ipv6/neigh/tunl0
/proc/sys/net/ipv6/neigh/vlan1
/proc/sys/net/ipv6/neigh/vlan33
/proc/sys/net/ipv6/routeBest regards,
=09=09=09Krzysztof Ol=EAdzki
... dealt with by eeb61f719c00c626115852bbc91189dc3011a844. Or are you
seeing those again?
--
No, probably not. Obviously, I'm in wrong HEAD after git-bisecting. Sorry.
Best regards,
=09=09=09=09Krzysztof Ol=EAdzki
| Benjamin Herrenschmidt | Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway |
| Ulrich Drepper | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| Washington Odhiambo | Weird Problem with NAT - more details |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
| Jarek Poplawski | [PATCH take 2] pkt_sched: Protect gen estimators under est_lock. |
| David Miller | Re: [GIT]: Networking |
