Warning when unloading the nf_conntack module (regression?)

Warning when unloading the nf_conntack module (regression?)

[Arjan van de Ven]

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_fini

The 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

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1026 bytes --]



On Sun, 3 Aug 2008, Arjan van de Ven wrote:

> 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_fini
>
> The 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

Thanks. It seems I'm the person who introduced it. I'll look at it ASAP.

Best regards,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1921 bytes --]



On Sun, 3 Aug 2008, Krzysztof Oledzki wrote:

>
>
> On Sun, 3 Aug 2008, Arjan van de Ven wrote:
>
>> 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_fini
>> 
>> The 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
>
> Thanks. It seems I'm the person who introduced it. I'll look at it ASAP.

Probably spoken too fast. This problem was introduced in 2.6.26-git15, 
about one week after my accounting rework had been included. Obviously 
there is something wrong with netfilter sysctl handling as starting with 
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 = 600
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1

Still investigating.

Best regards,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2232 bytes --]



On Mon, 4 Aug 2008, Krzysztof Oledzki wrote:

>
>
> On Sun, 3 Aug 2008, Krzysztof Oledzki wrote:
>
>> 
>> 
>> On Sun, 3 Aug 2008, Arjan van de Ven wrote:
>> 
>>> 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_fini
>>> 
>>> The 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
>> 
>> Thanks. It seems I'm the person who introduced it. I'll look at it ASAP.
>
> Probably spoken too fast. This problem was introduced in 2.6.26-git15, about 
> one week after my accounting rework had been included. Obviously there is 
> something wrong with netfilter sysctl handling as starting with 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 = 600
> net.netfilter.nf_conntrack_acct = 1
> net.netfilter.nf_conntrack_generic_timeout = 600
> net.netfilter.nf_conntrack_acct = 1
>
> Still investigating.

BTW: It also happens when I revert my patch:

sysctl -a|grep net.netfilter

net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_generic_timeout = 600

Best regards,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4885 bytes --]



On Mon, 4 Aug 2008, Krzysztof Oledzki wrote:

>
>
> On Mon, 4 Aug 2008, Krzysztof Oledzki wrote:
>
>> 
>> 
>> On Sun, 3 Aug 2008, Krzysztof Oledzki wrote:
>> 
>>> 
>>> 
>>> On Sun, 3 Aug 2008, Arjan van de Ven wrote:
>>> 
>>>> 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_fini
>>>> 
>>>> The 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
>>> 
>>> Thanks. It seems I'm the person who introduced it. I'll look at it ASAP.
>> 
>> Probably spoken too fast. This problem was introduced in 2.6.26-git15, 
>> about one week after my accounting rework had been included. Obviously 
>> there is something wrong with netfilter sysctl handling, as starting 
>> with 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 = 600
>> net.netfilter.nf_conntrack_acct = 1
>> net.netfilter.nf_conntrack_generic_timeout = 600
>> net.netfilter.nf_conntrack_acct = 1
>> 
>> Still investigating.
>
> BTW: It also happens when I revert my patch:
>
> sysctl -a|grep net.netfilter
>
> net.netfilter.nf_conntrack_generic_timeout = 600
> net.netfilter.nf_conntrack_generic_timeout = 600

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 resolve
   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 contortions
   induced by that.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

With this patch "sysctl -a|grep net.netfilter" shows only 
net.netfilter.nf_conntrack_generic_timeout and 
net.netfilter.nf_conntrack_acct, both are duplicate btw:

# sysctl -a 2>/dev/null|grep netf
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1

Without that commit I get full sysctl tree:

# sysctl -a 2>/dev/null|grep netf
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_max = 32768
net.netfilter.nf_conntrack_count = 0
net.netfilter.nf_conntrack_buckets = 8192
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 128

And of course no WARNING at unloading as it comes from that patch 
directly:

-       for (i = 1; table && (i <= depth); i++) {
-               ancestor = proc_sys_ancestor(dentry, i);
-               table = proc_sys_lookup_table_one(table, &ancestor->d_name);
-               if (table)
-                       table = table->child;
+       if (table && !table->child) {
+               WARN_ON(1);
+               goto out;
         }

OK, how we should proceed next? Is sysctl API misused somewhere in the 
netfilter code and/or in my 584015727a3b88b46602b20077b46cd04f8b4ab3 
patch? Or maybe 9043476f726802f4b00c96d0c4f418dde48d1304 commit is buggy?

Best regards,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Al Viro]

On Mon, Aug 04, 2008 at 09:41:10PM +0200, Krzysztof Oledzki wrote:

>> BTW: It also happens when I revert my patch:
>>
>> sysctl -a|grep net.netfilter
>>
>> net.netfilter.nf_conntrack_generic_timeout = 600
>> net.netfilter.nf_conntrack_generic_timeout = 600
>
> And the winner is... 9043476f726802f4b00c96d0c4f418dde48d1304:
>
> [PATCH] sanitize proc_sysctl

Almost definitely problems with registration order ;-/  I'll look into
that once I get a bit of sleep...

Re: Warning when unloading the nf_conntack module (regression?)

[Al Viro]

On Mon, Aug 04, 2008 at 09:00:58PM +0100, Al Viro wrote:
> On Mon, Aug 04, 2008 at 09:41:10PM +0200, Krzysztof Oledzki wrote:
> 
> >> BTW: It also happens when I revert my patch:
> >>
> >> sysctl -a|grep net.netfilter
> >>
> >> net.netfilter.nf_conntrack_generic_timeout = 600
> >> net.netfilter.nf_conntrack_generic_timeout = 600
> >
> > And the winner is... 9043476f726802f4b00c96d0c4f418dde48d1304:
> >
> > [PATCH] sanitize proc_sysctl
> 
> 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.

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2000 bytes --]



On Mon, 4 Aug 2008, Al Viro wrote:

> On Mon, Aug 04, 2008 at 09:00:58PM +0100, Al Viro wrote:
>> On Mon, Aug 04, 2008 at 09:41:10PM +0200, Krzysztof Oledzki wrote:
>>
>>>> BTW: It also happens when I revert my patch:
>>>>
>>>> sysctl -a|grep net.netfilter
>>>>
>>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>>
>>> And the winner is... 9043476f726802f4b00c96d0c4f418dde48d1304:
>>>
>>> [PATCH] sanitize proc_sysctl
>>
>> 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 
missing & duplicated:

# sysctl -a 2>/dev/null|grep net.netfilter
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_acct = 1

Plus, without nf_conntrack module loaded I get empty 
/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,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Al Viro]

On Mon, Aug 04, 2008 at 11:16:07PM +0200, Krzysztof Oledzki wrote:

> Solves partially: no more WARNING, however entries are still missing & 
> duplicated:
>
> # sysctl -a 2>/dev/null|grep net.netfilter
> net.netfilter.nf_conntrack_generic_timeout = 600
> net.netfilter.nf_conntrack_acct = 1
> net.netfilter.nf_conntrack_generic_timeout = 600
> net.netfilter.nf_conntrack_acct = 1

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...

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1646 bytes --]



On Mon, 4 Aug 2008, Al Viro wrote:

> On Mon, Aug 04, 2008 at 11:16:07PM +0200, Krzysztof Oledzki wrote:
>
>> Solves partially: no more WARNING, however entries are still missing &
>> duplicated:
>>
>> # sysctl -a 2>/dev/null|grep net.netfilter
>> net.netfilter.nf_conntrack_generic_timeout = 600
>> net.netfilter.nf_conntrack_acct = 1
>> net.netfilter.nf_conntrack_generic_timeout = 600
>> net.netfilter.nf_conntrack_acct = 1
>
> 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."

All I need to do is to load a single "nf_conntrack" module.

> 	... 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?

Indeed.

> _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[].

Will do. Thanks.

> 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 
again.

Best regards,

 				Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3050 bytes --]



On Tue, 5 Aug 2008, Krzysztof Oledzki wrote:

>
>
> On Mon, 4 Aug 2008, Al Viro wrote:
>
>> On Mon, Aug 04, 2008 at 11:16:07PM +0200, Krzysztof Oledzki wrote:
>> 
>>> Solves partially: no more WARNING, however entries are still missing &
>>> duplicated:
>>> 
>>> # sysctl -a 2>/dev/null|grep net.netfilter
>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>> net.netfilter.nf_conntrack_acct = 1
>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>> net.netfilter.nf_conntrack_acct = 1
>> 
>> 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."
>
> All I need to do is to load a single "nf_conntrack" module.
>
>> 	... 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?
>
> Indeed.
>
>> _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[].
>
> Will do. Thanks.
>
>> 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 again.

Both good and bad news. The good one is with two above fixes the netfilter 
issue seems to be now solved. However, starting from the
9043476f726802f4b00c96d0c4f418dde48d1304, even with NETFILNER=n, there are 
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/route

Best regards,

 			Krzysztof Olędzki

Re: Warning when unloading the nf_conntack module (regression?)

[Al Viro]

On Tue, Aug 05, 2008 at 03:08:17AM +0200, Krzysztof Oledzki wrote:
> issue seems to be now solved. However, starting from the
> 9043476f726802f4b00c96d0c4f418dde48d1304, even with NETFILNER=n, there are 
> other duplicated entries:
>
> # find /proc/sys -type d |sort|uniq -d
>
> /proc/sys/net/core
> /proc/sys/net/ipv4/route
> /proc/sys/net/ipv6

... dealt with by eeb61f719c00c626115852bbc91189dc3011a844.  Or are you
seeing those again?

Re: Warning when unloading the nf_conntack module (regression?)

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 628 bytes --]



On Tue, 5 Aug 2008, Al Viro wrote:

> On Tue, Aug 05, 2008 at 03:08:17AM +0200, Krzysztof Oledzki wrote:
>> issue seems to be now solved. However, starting from the
>> 9043476f726802f4b00c96d0c4f418dde48d1304, even with NETFILNER=n, there are
>> other duplicated entries:
>>
>> # find /proc/sys -type d |sort|uniq -d
>>
>> /proc/sys/net/core
>> /proc/sys/net/ipv4/route
>> /proc/sys/net/ipv6
>
> ... 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,

 				Krzysztof Olędzki