Most recent kernel where this bug did not occur: 2.6.22 (not sure) Distribution: custom Hardware Environment: See attached files Software Environment: See attached files. Problem Description: Changing a setting in /proc/sys/net/ipv[46]/conf/all does not propagate the setting to the individual network interfaces, for most settings. Steps to reproduce: # cat /proc/sys/net/ipv6/conf/{all,default,lo,eth0}/autoconf 1 1 1 1 # echo 0 > /proc/sys/net/ipv6/conf/all/autoconf # echo 0 > /proc/sys/net/ipv6/conf/default/autoconf # cat /proc/sys/net/ipv6/conf/{all,default,lo,eth0}/autoconf 0 0 1 1 The problem occurs for other settings than "autoconf", but not for all. "forwarding" is one which does work. Changing settings for individual interfaces still works. The problem is not specific to ipv6.
Created attachment 13274 [details] Kernel .config file This file is of a 2.6.23.1 kernel, but the problem still exists on 2.6.24-rc1.
Created attachment 13275 [details] output of dmesg This file is produced on a 2.6.23.1 kernel, but the problem still exists on 2.6.24-rc1.
Created attachment 13276 [details] Output of 'lspci -vvv' This file is produced on a 2.6.23.1 kernel, but the problem still exists on 2.6.24-rc1.
Created attachment 13277 [details] Output of ver_linux script
Created attachment 13278 [details] Contents of /proc/modules This file is produced on a 2.6.23.1 kernel, but the problem still exists on 2.6.24-rc1.
sysctl has the same problem: # sysctl net.ipv6.conf.eth0.autoconf net.ipv6.conf.eth0.autoconf = 1 # sysctl -w net.ipv6.conf.all.autoconf=0 net.ipv6.conf.all.autoconf = 0 # sysctl net.ipv6.conf.eth0.autoconf net.ipv6.conf.eth0.autoconf = 1
The bug has been reproduced by someone else on a different system: Linux dhcp12 2.6.23.1-z #1 SMP Tue Oct 23 12:21:44 CEST 2007 x86_64 GNU/Linux
Reply-To: akpm@linux-foundation.org On Thu, 25 Oct 2007 04:44:06 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9224 > > Summary: Settings to /proc/sys/net/ipv[46]/conf/all are not > propagated > Product: Networking > Version: 2.5 > KernelVersion: 2.6.24-rc1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: acme@ghostprotocols.net > ReportedBy: svdb+linux-kernel-bugs@stack.nl > > > Most recent kernel where this bug did not occur: 2.6.22 (not sure) > Distribution: custom > Hardware Environment: See attached files > Software Environment: See attached files. > Problem Description: Changing a setting in /proc/sys/net/ipv[46]/conf/all > does > not propagate the setting to the individual network interfaces, for most > settings. > > Steps to reproduce: > # cat /proc/sys/net/ipv6/conf/{all,default,lo,eth0}/autoconf > 1 > 1 > 1 > 1 > # echo 0 > /proc/sys/net/ipv6/conf/all/autoconf > # echo 0 > /proc/sys/net/ipv6/conf/default/autoconf > # cat /proc/sys/net/ipv6/conf/{all,default,lo,eth0}/autoconf > 0 > 0 > 1 > 1 > > The problem occurs for other settings than "autoconf", but not for all. > "forwarding" is one which does work. > > Changing settings for individual interfaces still works. > > The problem is not specific to ipv6. > Apparently a regression.
In article <20071025091652.0d7002c1.akpm@linux-foundation.org> (at Thu, 25 Oct 2007 09:16:52 -0700), Andrew Morton <akpm@linux-foundation.org> says: > > Most recent kernel where this bug did not occur: 2.6.22 (not sure) > Apparently a regression. I would say it is a bug, but it is not a regression. I mean, I believe this "bug" lives since 2.2. --yoshfuji
I don't think so; I noticed this bug when my ipv6 address did not resolve anymore because the autoconfigured ipv6 address was used when /proc/sys/net/ipv6/all/autoconf stopped working. I can see from log files that this happened at September 26, and 'last' tells me this is when I upgraded from 2.6.17 to 2.6.22. I guess it is possible that '/proc/.../all/...' was broken for a longer time if there was another reason why my manually configured ipv6 address was used during that time (Order of addresses? Changed default for 'autoconf'?). But I've never run 2.2 on this machine, and I'm sure .../all/... worked at some time; if the bug exists in some 2.2 kernel, it must have been backported. So I'm pretty sure this really is a regression. Although it could be that some settings in /proc/sys/net/ipv[46]/conf/all/ never worked, while it is a regression for others (like 'autoconf').
Please remove the blocker and the regression tag. It is not a regression, the behavior has been there at least a release or two. This is a bug, but just a normal one.
It is quite likely that this originated in 2.6.21. See http://bugzilla.kernel.org/show_bug.cgi?id=8519 for comparison.
Oh, so the "regression" tag is only to be used for regressions since the very last minor-version release? Should I have known this? (As in, did I miss some document I should have read before posting a bug?)