decnet: /proc/sys/net/decnet sysctl entries disappear

decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Beginning with kernel 2.6.27, the decnet kernel module /proc/sys/net/decnet sysctl entries disappear.  With the generous assistance of Eric Biederman, I have developed these patches to restore the previous behavior and add minor features.  (N.b, Eric verified kernel 3.4-rc1 no longer has this behavior.)

I have developed three sets of patches, to account for changes in the kernel networking APIs.

[-- Attachment #2: linux-2.6.27-decnet-sysctl.patch --]
[-- Type: application/octet-stream, Size: 7709 bytes --]

Title

linux-2.6.27-decnet-sysctl.patch

decnet kernel module patches for Linux 2.6.27 through 2.6.32

Author

Larry Baker
US Geological Survey
baker@usgs.gov

Description

The decnet kernel module is configured using entries under /proc/sys/net/decnet.
There are executor settings in /proc/sys/net/decnet, template device settings
in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active device
settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}.  All
Ethernet interfaces and the loopback interface are configured as DECnet devices
when the decnet kernel module is loaded.

The executor settings and template device settings are static; active device
settings are dynamic.  The active device settings for a network device are
copied from the appropriate template device settings when the network device is
configured as a DECnet device.  The active device settings are discarded when a
DECnet device is unconfigured (e.g., when the DECnet node address is set).

When the DECnet node address is set (e.g., by writing the new address to
/proc/sys/net/decnet/node_address) all DECnet devices are unconfigured, the new
DECnet node address is saved, and all Ethernet interfaces and the loopback
interface are reconfigured as DECnet devices.

When a DECnet device is unconfigured, its active device settings entries are
unregistered from the sysctl network namespace (/proc/sys/net).  When a DECnet
device is reconfigured, its active device settings entries are reregistered.

In kernel 2.6.27 the sysctl data structures were changed from a list to a tree.
The registration/unregistration behavior also changed.  As a result, when any
active device settings entries are unregistered, all the decnet kernel module
configuration settings entries in the sysctl network namespace are no longer
visible.  The only entries that are visible are the active device settings
entries that are reregistered when the DECnet devices are reconfigured.

The fix is to register an empty static /proc/sys/net/decnet/conf entry (ala
mkdir) before any of the (static or dynamic) entries beneath it are registered.
This workaround is not needed in 3.4 and later kernels.

After this patch, the registration order for sysctl entries is:

. Static executor entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active device entries in /proc/sys/net/decnet/conf/<dev-name>

Unregistration order is the reverse.

Other changes are:

. Updated banner
. DECnet device up/down KERN_INFO messages
. debug module parameter
. NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
. dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c

--- original/net/decnet/af_decnet.c
+++ patched/net/decnet/af_decnet.c
@@ -1,2 +1 @@
-
 /*
@@ -42,2 +41,5 @@
  *                          prepare for sendpage etc.
+ *            Larry Baker : Register static /proc/sys/net/decnet entries before
+ *                          dynamic /proc/sys/net/decnet/conf entries in
+ *                          dn_dev_init().
  */
@@ -2090,2 +2092,4 @@
 		case NETDEV_UP:
+			if (decnet_debug_level & 8)
+				printk(KERN_DEBUG "DECnet: %s NETDEV_UP", dev->name);
 			dn_dev_up(dev);
@@ -2093,2 +2097,4 @@
 		case NETDEV_DOWN:
+			if (decnet_debug_level & 8)
+				printk(KERN_DEBUG "DECnet: %s NETDEV_DOWN", dev->name);
 			dn_dev_down(dev);
@@ -2363,3 +2369,3 @@

-static char banner[] __initdata = KERN_INFO "NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team\n";
+static char banner[] __initdata = KERN_INFO "DECnet: DECnet for Linux: V.2.6.27 (C) 1995-2013 Linux DECnet Project Team\n";

@@ -2375,2 +2381,4 @@

+	dn_register_sysctl();
+
 	dn_neigh_init();
@@ -2385,3 +2393,2 @@
 	proc_net_fops_create(&init_net, "decnet", S_IRUGO, &dn_socket_seq_fops);
-	dn_register_sysctl();
 out:
@@ -2404,4 +2411,2 @@

-	dn_unregister_sysctl();
-
 	unregister_netdevice_notifier(&dn_dev_notifier);
@@ -2413,2 +2418,4 @@

+	dn_unregister_sysctl();
+
 	proc_net_remove(&init_net, "decnet");
--- original/net/decnet/dn_dev.c
+++ patched/net/decnet/dn_dev.c
@@ -24,2 +24,6 @@
  *                             devices. All mtu based now.
+ *               Larry Baker : Register empty static /proc/sys/net/decnet/conf
+ *                             before registering any entries beneath it due to
+ *                             tree-based sysctl tables since kernel 2.6.27.
+ *                             Workaround not needed in 3.4 and later kernels.
  */
@@ -60,3 +64,3 @@
 static char dn_rt_all_rt_mcast[ETH_ALEN]  = {0xAB,0x00,0x00,0x03,0x00,0x00};
-static char dn_hiord[ETH_ALEN]            = {0xAA,0x00,0x04,0x00,0x00,0x00};
+unsigned char dn_hiord[ETH_ALEN]          = {0xAA,0x00,0x04,0x00,0x00,0x00};
 static unsigned char dn_eco_version[3]    = {0x02,0x00,0x00};
@@ -172,2 +176,4 @@

+static struct ctl_table_header *dn_conf_path = NULL;
+
 static struct dn_dev_sysctl_table {
@@ -224,2 +230,13 @@

+static ctl_table empty[] = {
+        { }
+};
+
+static struct ctl_path dn_conf[] = {
+	{ .procname = "net", .ctl_name = CTL_NET, },
+	{ .procname = "decnet", .ctl_name = NET_DECNET, },
+	{ .procname = "conf", .ctl_name = NET_DECNET_CONF, },
+	{ },
+};
+
 static void dn_dev_sysctl_register(struct net_device *dev, struct dn_dev_parms *parms)
@@ -1176,2 +1193,3 @@
 	struct dn_dev *dn_db = (struct dn_dev *)dev->dn_ptr;
+	char dn_ascbuf[DN_ASCBUF_LEN];

@@ -1213,2 +1231,5 @@

+	dn_addr2asc(le16_to_cpu(addr), dn_ascbuf);
+	printk(KERN_INFO "DECnet: %s up [%s]", dev->name, dn_ascbuf);
+
 	/*
@@ -1256,2 +1277,3 @@
 	struct dn_ifaddr *ifa;
+	__le16 addr = decnet_address;

@@ -1266,2 +1288,14 @@
 	dn_dev_delete(dev);
+
+	if (dev->type == ARPHRD_ETHER) {
+		if (memcmp(dev->dev_addr, dn_hiord, 4) != 0)
+			return;
+		addr = dn_eth2dn(dev->dev_addr);
+	}
+
+	if (addr == 0)
+		return;
+
+	printk(KERN_INFO "DECnet: %s down", dev->name);
+
 }
@@ -1432,2 +1466,6 @@

+static int debug = 0;
+module_param(debug, int, 0444);
+MODULE_PARM_DESC(debug, "Debug level");
+
 static int addr[2];
@@ -1438,2 +1476,4 @@
 {
+	decnet_debug_level = debug;
+
 	if (addr[0] > 63 || addr[0] < 0) {
@@ -1450,11 +1490,4 @@

-	dn_dev_devices_on();
-
-	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL);
-	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL);
-	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr);
-
-	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
-
 #ifdef CONFIG_SYSCTL
+	dn_conf_path = register_sysctl_paths(dn_conf, empty);
 	{
@@ -1465,2 +1498,10 @@
 #endif /* CONFIG_SYSCTL */
+
+	dn_dev_devices_on();
+
+	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL);
+	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL);
+	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr);
+
+	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
 }
@@ -1469,2 +1510,6 @@
 {
+	proc_net_remove(&init_net, "decnet_dev");
+
+	dn_dev_devices_off();
+
 #ifdef CONFIG_SYSCTL
@@ -1475,7 +1520,4 @@
 	}
+	unregister_sysctl_table(dn_conf_path);
 #endif /* CONFIG_SYSCTL */
-
-	proc_net_remove(&init_net, "decnet_dev");
-
-	dn_dev_devices_off();
 }
--- original/net/decnet/dn_route.c
+++ patched/net/decnet/dn_route.c
@@ -100,4 +100,3 @@

-
-static unsigned char dn_hiord_addr[6] = {0xAA,0x00,0x04,0x00,0x00,0x00};
+extern unsigned char dn_hiord[ETH_ALEN];

@@ -504,3 +504,3 @@
 	cb->dst = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;
@@ -512,3 +512,3 @@
 	cb->src = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;

[-- Attachment #3: linux-2.6.33-decnet-sysctl.patch --]
[-- Type: application/octet-stream, Size: 7704 bytes --]

Title

linux-2.6.33-decnet-sysctl.patch

decnet kernel module patches for Linux 2.6.33 through 3.4.x

Author

Larry Baker
US Geological Survey
baker@usgs.gov

Description

The decnet kernel module is configured using entries under /proc/sys/net/decnet.
There are executor settings in /proc/sys/net/decnet, template device settings
in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active device
settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}.  All
Ethernet interfaces and the loopback interface are configured as DECnet devices
when the decnet kernel module is loaded.

The executor settings and template device settings are static; active device
settings are dynamic.  The active device settings for a network device are
copied from the appropriate template device settings when the network device is
configured as a DECnet device.  The active device settings are discarded when a
DECnet device is unconfigured (e.g., when the DECnet node address is set).

When the DECnet node address is set (e.g., by writing the new address to
/proc/sys/net/decnet/node_address) all DECnet devices are unconfigured, the new
DECnet node address is saved, and all Ethernet interfaces and the loopback
interface are reconfigured as DECnet devices.

When a DECnet device is unconfigured, its active device settings entries are
unregistered from the sysctl network namespace (/proc/sys/net).  When a DECnet
device is reconfigured, its active device settings entries are reregistered.

In kernel 2.6.27 the sysctl data structures were changed from a list to a tree.
The registration/unregistration behavior also changed.  As a result, when any
active device settings entries are unregistered, all the decnet kernel module
configuration settings entries in the sysctl network namespace are no longer
visible.  The only entries that are visible are the active device settings
entries that are reregistered when the DECnet devices are reconfigured.

The fix is to register an empty static /proc/sys/net/decnet/conf entry (ala
mkdir) before any of the (static or dynamic) entries beneath it are registered.
This workaround is not needed in 3.4 and later kernels.

After this patch, the registration order for sysctl entries is:

. Static executor entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active device entries in /proc/sys/net/decnet/conf/<dev-name>

Unregistration order is the reverse.

Other changes are:

. Updated banner
. DECnet device up/down KERN_INFO messages
. debug module parameter
. NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
. dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c

--- original/net/decnet/af_decnet.c
+++ patched/net/decnet/af_decnet.c
@@ -1,2 +1 @@
-
 /*
@@ -42,2 +41,5 @@
  *                          prepare for sendpage etc.
+ *            Larry Baker : Register static /proc/sys/net/decnet entries before
+ *                          dynamic /proc/sys/net/decnet/conf entries in
+ *                          dn_dev_init().
  */
@@ -2091,2 +2093,4 @@
 	case NETDEV_UP:
+		if (decnet_debug_level & 8)
+			printk(KERN_DEBUG "DECnet: %s NETDEV_UP", dev->name);
 		dn_dev_up(dev);
@@ -2094,2 +2098,4 @@
 	case NETDEV_DOWN:
+		if (decnet_debug_level & 8)
+			printk(KERN_DEBUG "DECnet: %s NETDEV_DOWN", dev->name);
 		dn_dev_down(dev);
@@ -2364,3 +2370,3 @@

-static char banner[] __initdata = KERN_INFO "NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team\n";
+static char banner[] __initdata = KERN_INFO "DECnet: DECnet for Linux: V.2.6.33 (C) 1995-2013 Linux DECnet Project Team\n";

@@ -2376,2 +2382,4 @@

+	dn_register_sysctl();
+
 	dn_neigh_init();
@@ -2386,3 +2394,2 @@
 	proc_net_fops_create(&init_net, "decnet", S_IRUGO, &dn_socket_seq_fops);
-	dn_register_sysctl();
 out:
@@ -2405,4 +2412,2 @@

-	dn_unregister_sysctl();
-
 	unregister_netdevice_notifier(&dn_dev_notifier);
@@ -2414,2 +2419,4 @@

+	dn_unregister_sysctl();
+
 	proc_net_remove(&init_net, "decnet");
--- original/net/decnet/dn_dev.c
+++ patched/net/decnet/dn_dev.c
@@ -24,2 +24,6 @@
  *                             devices. All mtu based now.
+ *               Larry Baker : Register empty static /proc/sys/net/decnet/conf
+ *                             before registering any entries beneath it due to
+ *                             tree-based sysctl tables since kernel 2.6.27.
+ *                             Workaround not needed in 3.4 and later kernels.
  */
@@ -61,3 +65,3 @@
 static char dn_rt_all_rt_mcast[ETH_ALEN]  = {0xAB,0x00,0x00,0x03,0x00,0x00};
-static char dn_hiord[ETH_ALEN]            = {0xAA,0x00,0x04,0x00,0x00,0x00};
+unsigned char dn_hiord[ETH_ALEN]          = {0xAA,0x00,0x04,0x00,0x00,0x00};
 static unsigned char dn_eco_version[3]    = {0x02,0x00,0x00};
@@ -163,2 +167,5 @@
 			void __user *, size_t *, loff_t *);
+
+static struct ctl_table_header *dn_conf_path = NULL;
+
 static struct dn_dev_sysctl_table {
@@ -207,2 +214,13 @@

+static ctl_table empty[] = {
+        { }
+};
+
+static struct ctl_path dn_conf[] = {
+	{ .procname = "net", },
+	{ .procname = "decnet", },
+	{ .procname = "conf", },
+	{ },
+};
+
 static void dn_dev_sysctl_register(struct net_device *dev, struct dn_dev_parms *parms)
@@ -1143,2 +1161,3 @@
 	struct dn_dev *dn_db = rtnl_dereference(dev->dn_ptr);
+	char dn_ascbuf[DN_ASCBUF_LEN];

@@ -1180,2 +1199,5 @@

+	dn_addr2asc(le16_to_cpu(addr), dn_ascbuf);
+	printk(KERN_INFO "DECnet: %s up [%s]", dev->name, dn_ascbuf);
+
 	/*
@@ -1223,2 +1245,3 @@
 	struct dn_ifaddr *ifa;
+	__le16 addr = decnet_address;

@@ -1233,2 +1256,14 @@
 	dn_dev_delete(dev);
+
+	if (dev->type == ARPHRD_ETHER) {
+		if (memcmp(dev->dev_addr, dn_hiord, 4) != 0)
+			return;
+		addr = dn_eth2dn(dev->dev_addr);
+	}
+
+	if (addr == 0)
+		return;
+
+	printk(KERN_INFO "DECnet: %s down", dev->name);
+
 }
@@ -1396,2 +1431,6 @@

+static int debug = 0;
+module_param(debug, int, 0444);
+MODULE_PARM_DESC(debug, "Debug level");
+
 static int addr[2];
@@ -1402,2 +1441,4 @@
 {
+	decnet_debug_level = debug;
+
 	if (addr[0] > 63 || addr[0] < 0) {
@@ -1414,11 +1455,4 @@

-	dn_dev_devices_on();
-
-	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL, NULL);
-	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL, NULL);
-	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr, NULL);
-
-	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
-
 #ifdef CONFIG_SYSCTL
+	dn_conf_path = register_sysctl_paths(dn_conf, empty);
 	{
@@ -1429,2 +1463,10 @@
 #endif /* CONFIG_SYSCTL */
+
+	dn_dev_devices_on();
+
+	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL, NULL);
+	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL, NULL);
+	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr, NULL);
+
+	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
 }
@@ -1433,2 +1475,6 @@
 {
+	proc_net_remove(&init_net, "decnet_dev");
+
+	dn_dev_devices_off();
+
 #ifdef CONFIG_SYSCTL
@@ -1439,7 +1485,4 @@
 	}
+	unregister_sysctl_table(dn_conf_path);
 #endif /* CONFIG_SYSCTL */
-
-	proc_net_remove(&init_net, "decnet_dev");
-
-	dn_dev_devices_off();
 }
--- original/net/decnet/dn_route.c
+++ patched/net/decnet/dn_route.c
@@ -101,4 +101,3 @@

-
-static unsigned char dn_hiord_addr[6] = {0xAA,0x00,0x04,0x00,0x00,0x00};
+extern unsigned char dn_hiord[ETH_ALEN];

@@ -527,3 +526,3 @@
 	cb->dst = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;
@@ -535,3 +534,3 @@
 	cb->src = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;

[-- Attachment #4: linux-3.5-decnet-sysctl.patch --]
[-- Type: application/octet-stream, Size: 8165 bytes --]

Title

linux-3.5-decnet-sysctl.patch

decnet kernel module patches for Linux 3.5 and later

Author

Larry Baker
US Geological Survey
baker@usgs.gov

Description

The decnet kernel module is configured using entries under /proc/sys/net/decnet.
There are executor settings in /proc/sys/net/decnet, template device settings
in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active device
settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}.  All
Ethernet interfaces and the loopback interface are configured as DECnet devices
when the decnet kernel module is loaded.

The executor settings and template device settings are static; active device
settings are dynamic.  The active device settings for a network device are
copied from the appropriate template device settings when the network device is
configured as a DECnet device.  The active device settings are discarded when a
DECnet device is unconfigured (e.g., when the DECnet node address is set).

When the DECnet node address is set (e.g., by writing the new address to
/proc/sys/net/decnet/node_address) all DECnet devices are unconfigured, the new
DECnet node address is saved, and all Ethernet interfaces and the loopback
interface are reconfigured as DECnet devices.

When a DECnet device is unconfigured, its active device settings entries are
unregistered from the sysctl network namespace (/proc/sys/net).  When a DECnet
device is reconfigured, its active device settings entries are reregistered.

In kernel 2.6.27 the sysctl data structures were changed from a list to a tree.
The registration/unregistration behavior also changed.  As a result, when any
active device settings entries are unregistered, all the decnet kernel module
configuration settings entries in the sysctl network namespace are no longer
visible.  The only entries that are visible are the active device settings
entries that are reregistered when the DECnet devices are reconfigured.

The fix is to register an empty static /proc/sys/net/decnet/conf entry (ala
mkdir) before any of the (static or dynamic) entries beneath it are registered.
This workaround is not needed in 3.4 and later kernels.

After this patch, the registration order for sysctl entries is:

. Static executor entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active device entries in /proc/sys/net/decnet/conf/<dev-name>

Unregistration order is the reverse.

Other changes are:

. Updated banner
. DECnet device up/down KERN_INFO messages
. debug module parameter
. NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
. dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c

--- original/net/decnet/af_decnet.c
+++ patched/net/decnet/af_decnet.c
@@ -1,2 +1 @@
-
 /*
@@ -42,2 +41,5 @@
  *                          prepare for sendpage etc.
+ *            Larry Baker : Register static /proc/sys/net/decnet entries before
+ *                          dynamic /proc/sys/net/decnet/conf entries in
+ *                          dn_dev_init().
  */
@@ -2090,2 +2092,4 @@
 	case NETDEV_UP:
+		if (decnet_debug_level & 8)
+			printk(KERN_DEBUG "DECnet: %s NETDEV_UP", dev->name);
 		dn_dev_up(dev);
@@ -2093,2 +2097,4 @@
 	case NETDEV_DOWN:
+		if (decnet_debug_level & 8)
+			printk(KERN_DEBUG "DECnet: %s NETDEV_DOWN", dev->name);
 		dn_dev_down(dev);
@@ -2363,3 +2369,3 @@

-static char banner[] __initdata = KERN_INFO "NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team\n";
+static char banner[] __initdata = KERN_INFO "DECnet: DECnet for Linux: V.3.5 (C) 1995-2013 Linux DECnet Project Team\n";

@@ -2375,2 +2381,4 @@

+	dn_register_sysctl();
+
 	dn_neigh_init();
@@ -2385,3 +2393,2 @@
 	proc_net_fops_create(&init_net, "decnet", S_IRUGO, &dn_socket_seq_fops);
-	dn_register_sysctl();
 out:
@@ -2404,4 +2411,2 @@

-	dn_unregister_sysctl();
-
 	unregister_netdevice_notifier(&dn_dev_notifier);
@@ -2413,2 +2418,4 @@

+	dn_unregister_sysctl();
+
 	proc_net_remove(&init_net, "decnet");
--- original/net/decnet/dn_dev.c
+++ patched/net/decnet/dn_dev.c
@@ -24,2 +24,6 @@
  *                             devices. All mtu based now.
+ *               Larry Baker : Register empty static /proc/sys/net/decnet/conf
+ *                             before registering any entries beneath it due to
+ *                             tree-based sysctl tables since kernel 2.6.27.
+ *                             Workaround not needed in 3.4 and later kernels.
  */
@@ -60,3 +64,3 @@
 static char dn_rt_all_rt_mcast[ETH_ALEN]  = {0xAB,0x00,0x00,0x03,0x00,0x00};
-static char dn_hiord[ETH_ALEN]            = {0xAA,0x00,0x04,0x00,0x00,0x00};
+unsigned char dn_hiord[ETH_ALEN]          = {0xAA,0x00,0x04,0x00,0x00,0x00};
 static unsigned char dn_eco_version[3]    = {0x02,0x00,0x00};
@@ -162,2 +166,5 @@
 			void __user *, size_t *, loff_t *);
+
+static struct ctl_table_header *dn_conf_path = NULL;
+
 static struct dn_dev_sysctl_table {
@@ -206,2 +213,8 @@

+static ctl_table empty[] = {
+        { }
+};
+
+static const char dn_conf[] = "net/decnet/conf";
+
 static void dn_dev_sysctl_register(struct net_device *dev, struct dn_dev_parms *parms)
@@ -211,3 +224,3 @@

-	char path[sizeof("net/decnet/conf/") + IFNAMSIZ];
+	char dn_ctl_path[sizeof(dn_conf) + 1 + IFNAMSIZ];

@@ -222,4 +235,4 @@

-	snprintf(path, sizeof(path), "net/decnet/conf/%s",
-		dev? dev->name : parms->name);
+	snprintf(dn_ctl_path, sizeof(dn_ctl_path), "%s/%s", dn_conf,
+		dev ? dev->name : parms->name);

@@ -227,3 +240,3 @@

-	t->sysctl_header = register_net_sysctl(&init_net, path, t->dn_dev_vars);
+	t->sysctl_header = register_net_sysctl(&init_net, dn_ctl_path, t->dn_dev_vars);
 	if (t->sysctl_header == NULL)
@@ -1131,2 +1144,3 @@
 	struct dn_dev *dn_db = rtnl_dereference(dev->dn_ptr);
+	char dn_ascbuf[DN_ASCBUF_LEN];

@@ -1168,2 +1182,5 @@

+	dn_addr2asc(le16_to_cpu(addr), dn_ascbuf);
+	printk(KERN_INFO "DECnet: %s up [%s]", dev->name, dn_ascbuf);
+
 	/*
@@ -1211,2 +1228,3 @@
 	struct dn_ifaddr *ifa;
+	__le16 addr = decnet_address;

@@ -1221,2 +1239,14 @@
 	dn_dev_delete(dev);
+
+	if (dev->type == ARPHRD_ETHER) {
+		if (memcmp(dev->dev_addr, dn_hiord, 4) != 0)
+			return;
+		addr = dn_eth2dn(dev->dev_addr);
+	}
+
+	if (addr == 0)
+		return;
+
+	printk(KERN_INFO "DECnet: %s down", dev->name);
+
 }
@@ -1384,2 +1414,6 @@

+static int debug = 0;
+module_param(debug, int, 0444);
+MODULE_PARM_DESC(debug, "Debug level");
+
 static int addr[2];
@@ -1390,2 +1424,4 @@
 {
+	decnet_debug_level = debug;
+
 	if (addr[0] > 63 || addr[0] < 0) {
@@ -1402,11 +1438,4 @@

-	dn_dev_devices_on();
-
-	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL, NULL);
-	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL, NULL);
-	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr, NULL);
-
-	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
-
 #ifdef CONFIG_SYSCTL
+	dn_conf_path = register_net_sysctl(&init_net, dn_conf, empty);
 	{
@@ -1417,2 +1446,10 @@
 #endif /* CONFIG_SYSCTL */
+
+	dn_dev_devices_on();
+
+	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL, NULL);
+	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL, NULL);
+	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr, NULL);
+
+	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
 }
@@ -1421,2 +1458,6 @@
 {
+	proc_net_remove(&init_net, "decnet_dev");
+
+	dn_dev_devices_off();
+
 #ifdef CONFIG_SYSCTL
@@ -1427,7 +1468,4 @@
 	}
+	unregister_net_sysctl_table(dn_conf_path);
 #endif /* CONFIG_SYSCTL */
-
-	proc_net_remove(&init_net, "decnet_dev");
-
-	dn_dev_devices_off();
 }
--- original/net/decnet/dn_route.c
+++ patched/net/decnet/dn_route.c
@@ -102,4 +102,3 @@

-
-static unsigned char dn_hiord_addr[6] = {0xAA,0x00,0x04,0x00,0x00,0x00};
+extern unsigned char dn_hiord[ETH_ALEN];

@@ -528,3 +527,3 @@
 	cb->dst = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;
@@ -536,3 +535,3 @@
 	cb->src = dn_eth2dn(ptr);
-	if (memcmp(ptr, dn_hiord_addr, 4) != 0)
+	if (memcmp(ptr, dn_hiord, 4) != 0)
 		goto drop_it;

[-- Attachment #5: Type: text/plain, Size: 3815 bytes --]



. linux-2.6.27-decnet-sysctl.patch

  decnet kernel module patches for Linux 2.6.27 through 2.6.32 (tree-structured sysctl, struct ctl_path includes .ctl_name)

. linux-2.6.33-decnet-sysctl.patch

  decnet kernel module patches for Linux 2.6.33 through 3.4.x (struct ctl_path no longer includes .ctl_name, rtnl_register() adds rtnl_calcit_func calcit)

. linux-3.5-decnet-sysctl.patch

  decnet kernel module patches for Linux 3.5 and later (register_net_sysctl()/unregister_net_sysctl_table() in place of register_sysctl_paths()/unregister_sysctl_table())

I am running linux-2.6.27-decnet-sysctl.patch on a CentOS 6.3 x86_64 system (Linux atompc.wr.usgs.gov 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux).

I am running linux-2.6.33-decnet-sysctl.patch on an Arch Linux ARM 3.1.10 system (Linux sheeva 3.1.10-15-ARCH #1 PREEMPT Wed Dec 12 15:25:18 UTC 2012 armv5tel GNU/Linux).

I do not have the ability to test linux-3.5-decnet-sysctl.patch.  I compared linux-2.6.33-decnet-sysctl.patch to linux-3.5-decnet-sysctl.patch, and inspected the patched files visually.

Description

The decnet kernel module is configured using entries under /proc/sys/net/decnet.  There are executor settings in /proc/sys/net/decnet, template device settings in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active device settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}.  All Ethernet interfaces and the loopback interface are configured as DECnet devices when the decnet kernel module is loaded.

The executor settings and template device settings are static; active device settings are dynamic.  The active device settings for a network device are copied from the appropriate template device settings when the network device is configured as a DECnet device.  The active device settings are discarded when a DECnet device is unconfigured (e.g., when the DECnet node address is set).

When the DECnet node address is set (e.g., by writing the new address to /proc/sys/net/decnet/node_address) all DECnet devices are unconfigured, the new DECnet node address is saved, and all Ethernet interfaces and the loopback interface are reconfigured as DECnet devices.

When a DECnet device is unconfigured, its active device settings entries are unregistered from the sysctl network namespace (/proc/sys/net).  When a DECnet device is reconfigured, its active device settings entries are reregistered.

In kernel 2.6.27 the sysctl data structures were changed from a list to a tree.  The registration/unregistration behavior also changed.  As a result, when any active device settings entries are unregistered, all the decnet kernel module configuration settings entries in the sysctl network namespace are no longer visible.  The only entries that are visible are the active device settings entries that are reregistered when the DECnet devices are reconfigured.

The fix is to register an empty static /proc/sys/net/decnet/conf entry (ala mkdir) before any of the (static or dynamic) entries beneath it are registered.  This workaround is not needed in 3.4 and later kernels.

After this patch, the registration order for sysctl entries is:

. Static executor entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active device entries in /proc/sys/net/decnet/conf/<dev-name>

Unregistration order is the reverse.

Other changes are:

. Updated banner
. DECnet device up/down KERN_INFO messages
. debug module parameter
. NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
. dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Ben Hutchings]

Please read and follow the advice in Documentation/SubmittingPatches,
including in particular about the Developer's Certificate of Origin.

On Tue, 2013-02-12 at 00:26 +0000, Larry Baker wrote:
[...]
> Other changes are:
> 
> . Updated banner
> . DECnet device up/down KERN_INFO messages
> . debug module parameter
> . NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
> . dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c

Each patch should do one thing.  So send one patch with the sysctl
patch, and additional patches for the other changes.

> --- original/net/decnet/af_decnet.c
> +++ patched/net/decnet/af_decnet.c
> @@ -1,2 +1 @@
> -
>  /*
> @@ -42,2 +41,5 @@
>   *                          prepare for sendpage etc.
> + *            Larry Baker : Register static /proc/sys/net/decnet entries before
> + *                          dynamic /proc/sys/net/decnet/conf entries in
> + *                          dn_dev_init().
>   */
[...]

There is no log changes in file headers; this information is all
recorded by the git version control system.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Ben Hutchings]

Sorry, I'm making more than the usual rate of errors today; let me
correct myself:

On Tue, 2013-02-12 at 00:46 +0000, Ben Hutchings wrote:
> Please read and follow the advice in Documentation/SubmittingPatches,
> including in particular about the Developer's Certificate of Origin.
> 
> On Tue, 2013-02-12 at 00:26 +0000, Larry Baker wrote:
> [...]
> > Other changes are:
> > 
> > . Updated banner
> > . DECnet device up/down KERN_INFO messages
> > . debug module parameter
> > . NETDEV_UP/DOWN KERN_DEBUG messages if (debug & 8)
> > . dn_route.c uses dn_hiord[ETH_ALEN] in dn_dev.c
> 
> Each patch should do one thing.  So send one patch with the sysctl
> patch, and additional patches for the other changes.

Each patch should do one thing.  So send one patch with the sysctl fix,
and additional patches for the other changes.

> > --- original/net/decnet/af_decnet.c
> > +++ patched/net/decnet/af_decnet.c
> > @@ -1,2 +1 @@
> > -
> >  /*
> > @@ -42,2 +41,5 @@
> >   *                          prepare for sendpage etc.
> > + *            Larry Baker : Register static /proc/sys/net/decnet entries before
> > + *                          dynamic /proc/sys/net/decnet/conf entries in
> > + *                          dn_dev_init().
> >   */
> [...]
> 
> There is no log changes in file headers; this information is all
> recorded by the git version control system.

There is no need to log changes in file headers; this information is all
recorded by the git version control system.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[David Miller]

Attachments are not the correct way to submit a series of patches.

Please read Documentation/SubmittingPatches

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

On 11 Feb 2013, at 5:01 PM, Ben Hutchings wrote:

> Each patch should do one thing.  So send one patch with the sysctl fix,
> and additional patches for the other changes.

The decnet module banner has not changed in many years; that is why I changed it.  I also used a numbering scheme for the banner that matched the patch file name.  Should each of my patch submissions update the banner?  Or, does the decnet module maintainer do that?

FYI.  As of a couple years or so ago, the person that used to do this on the linux-decnet-user@lists.sourceforge.net moved on.  I'm trying to help others like myself that use this code.  Thankfully, someone has been updating it as the kernel network APIs have been changing.  I have to find out from someone here in our IT management what I am allowed to sign/agree to.  As you can see, I work for the US Government; I don't get to decide what I am authorized to commit the government to.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

David,

On 11 Feb 2013, at 5:09 PM, David Miller wrote:

> 
> Attachments are not the correct way to submit a series of patches.
> 
> Please read Documentation/SubmittingPatches
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I found scripts/get_maintainer.pl lists you as a maintainer of the decnet code.  It also lists Chrissie Caulfield, but she has pretty much bowed out -- she's the one that told me to send my patches to the net-dev list.

To make this go as smoothly as possible, I'd like your advice about what I should do.  So, my first question is: should I submit a bug report describing the faulty behavior and my diagnosis while I work on pruning my patches?  To netdev@vger.kernel.org?  Second: I made three patch files to account for the API changes to the kernel over time.  Should those be individual submissions, related somehow by the tag in [PATCH tag]?  Suggestions?

Who changes the banner, me or you?  Do you have a recommendation for choosing the version in the banner?

Eric Biederman fixed the root cause of the faulty behavior in kernel 3.4-rc1.  None of my systems are that new.  He told me about patching stable kernels.

> But there are people who collect bug fixes and apply them to older
> kernels as long as a fix has been made to Linus's kernel and I would
> be happy to do a bit of code review and forward those patches
> to stable@vger.kernel.org if you that is what you are interested in
> doing with them.


Since the current kernel code has apparently fixed the problem, should I send my work to Eric/stable@vger.kernel.org instead of netdev@vger.kernel.org?  I do not want to annoy anyone with issues that might seem trivial to most people -- most people have probably never heard of DECnet.

Thank you in advance for your time.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

David,

On 11 Feb 2013, at 8:53 PM, David Miller wrote:

> 
> Never email developers privately, ever.  It is both rude and
> also a very poor use of global developer resources.
> 
> Always ask on the appropriate, public, mailing list, so that
> any developer, not just me, can answer you.

I'm sorry you feel this way.  Other developers have been very gracious in offering assistance and encouragement to solve this problem.  I was following the instructions in Documentation/SubmittingPatches you guided me to.  Specifically, the instructions to locate the assigned maintainer and "e-mail that person".

> 5) Select e-mail destination.
> 
> Look through the MAINTAINERS file and the source code, and determine
> if your change applies to a specific subsystem of the kernel, with
> an assigned maintainer.  If so, e-mail that person.  The script
> scripts/get_maintainer.pl can be very useful at this step.
> 
> If no maintainer is listed, or the maintainer does not respond, send
> your patch to the primary Linux kernel developer's mailing list,
> linux-kernel@vger.kernel.org.  Most kernel developers monitor this
> e-mail list, and can comment on your changes.

scripts/get_maintainer.pl said that was you.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Joe Perches]

On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
> > Never email developers privately, ever.  It is both rude and
> > also a very poor use of global developer resources.
> > 
> > Always ask on the appropriate, public, mailing list, so that
> > any developer, not just me, can answer you.
[]
> scripts/get_maintainer.pl said that was you.

It also said the netdev and lkml mailing lists.

I presume David is objecting not to the email,
but to the email without the cc's to the
appropriate mailing lists.

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Ben Hutchings]

On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
> David,
> 
> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
> 
> > 
> > Never email developers privately, ever.  It is both rude and
> > also a very poor use of global developer resources.
> > 
> > Always ask on the appropriate, public, mailing list, so that
> > any developer, not just me, can answer you.
> 
> I'm sorry you feel this way.  Other developers have been very gracious
> in offering assistance and encouragement to solve this problem.  I was
> following the instructions in Documentation/SubmittingPatches you
> guided me to.  Specifically, the instructions to locate the assigned
> maintainer and "e-mail that person".

It should also say to mail the related list(s); that's apparently a
documentation error.

> > 5) Select e-mail destination.
> > 
> > Look through the MAINTAINERS file and the source code, and determine
> > if your change applies to a specific subsystem of the kernel, with
> > an assigned maintainer.  If so, e-mail that person.  The script
> > scripts/get_maintainer.pl can be very useful at this step.
> > 
> > If no maintainer is listed, or the maintainer does not respond, send
> > your patch to the primary Linux kernel developer's mailing list,
> > linux-kernel@vger.kernel.org.  Most kernel developers monitor this
> > e-mail list, and can comment on your changes.
> 
> scripts/get_maintainer.pl said that was you.

David Miller is in overall charge of networking, so for any code under
drivers/net/ or net/ that doesn't have its own maintainer, he'll show up
as the primary maintainer.  But in reality I doubt he spends much time
thinking about relatively obscure areas that have lost their specialist
maintainer.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

Joe,

On 12 Feb 2013, at 10:43 AM, Joe Perches wrote:

> On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
>> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
>>> Never email developers privately, ever.  It is both rude and
>>> also a very poor use of global developer resources.
>>> 
>>> Always ask on the appropriate, public, mailing list, so that
>>> any developer, not just me, can answer you.
> []
>> scripts/get_maintainer.pl said that was you.
> 
> It also said the netdev and lkml mailing lists.
> 
> I presume David is objecting not to the email,
> but to the email without the cc's to the
> appropriate mailing lists.
> 
> 

The instructions say "e-mail that person".  There are only two persons listed as decnet maintainers, one of which has told me she is not involved much any more.  The instructions only mention sending to mailing lists if the maintainer does not respond.

I explicitly followed the instructions.

If the developers want mailing lists CC'd right off the bat, the instructions should be updated.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Joe Perches]

On Tue, 2013-02-12 at 10:58 -0800, Larry Baker wrote:
> The instructions say "e-mail that person".  There are only two persons
> listed as decnet maintainers, one of which has told me she is not
> involved much any more.  The instructions only mention sending to
> mailing lists if the maintainer does not respond.
> 
> I explicitly followed the instructions.

I think you need to read a little farther.

> If the developers want mailing lists CC'd right off the bat, the instructions should be updated.

from: Documentation/SubmittingPatches

6) Select your CC (e-mail carbon copy) list.

Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.

PROBLEM: decnet: /proc/sys/net/decnet sysctl entries disappear (2.6.27 through 3.3.x)

[Larry Baker]

PROBLEM

decnet: /proc/sys/net/decnet sysctl entries disappear (2.6.27 through 3.3.x)

DESCRIPTION

The decnet kernel module is configured using entries under /proc/sys/net/decnet.  There are DECnet executor (host) node settings in /proc/sys/net/decnet, template network device settings in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active network device settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}.  The normal sequence is to load the decnet module, configure the module, then load a deamon to handle remote file access requests.

When I load the decnet module and configure it on the latest Arch Linux ARM kernel (3.1.10-15-ARCH), most of the /proc/sys/net/decnet sysctl entries disappear.  I found the same behavior when I tested the decnet module on the latest CentOS (Red Hat) 6.3 x86_64 kernel (2.6.32-279.19.1.el6.x86_64).  The latest CentOS 5.9 i386 kernel (2.6.18-348.1.1.el5) does not exhibit this behavior; the CentOS 6.0 i386 kernel (2.6.32-71.el6.i686) is the earliest CentOS kernel that exhibits this behavior.

This is the expected behavior (CentOS 5.9 i386):

> # modprobe decnet   <--- load the decnet kernel module

> # ls /proc/sys/net/decnet   <--- there are static sysctl entries in /proc/sys/net/decnet
> conf        decnet_rmem     di_count  dst_gc_interval  no_fc_max_cwnd
> debug       decnet_wmem     dn_count  node_address     time_wait
> decnet_mem  default_device  dr_count  node_name

> # ls /proc/sys/net/decnet/conf   <--- there are both static and dynamic (eth0 and lo) sysctl entries in /proc/sys/net/decnet/conf
> ddcmp  eth0  ethernet  ipgre  lo  loopback

> # echo 0.0 >/proc/sys/net/decnet/node_address   <--- set the DECnet node address (the number does not matter)

> # ls /proc/sys/net/decnet   <--- the sysctl entries in /proc/sys/net/decnet are still there
> conf        decnet_rmem     di_count  dst_gc_interval  no_fc_max_cwnd
> debug       decnet_wmem     dn_count  node_address     time_wait
> decnet_mem  default_device  dr_count  node_name

> # ls /proc/sys/net/decnet/conf   <--- so are the sysctl entries in /proc/sys/net/decnet/conf
> ddcmp  eth0  ethernet  ipgre  lo  loopback

This is the aberrant behavior (CentOS 6.0 i386):

> # modprobe decnet

> # ls /proc/sys/net/decnet
> conf        decnet_rmem     di_count  dst_gc_interval  no_fc_max_cwnd
> debug       decnet_wmem     dn_count  node_address     time_wait
> decnet_mem  default_device  dr_count  node_name

> # ls /proc/sys/net/decnet/conf
> ddcmp  eth0  ethernet  ipgre  lo  loopback

> # echo 0.0 >/proc/sys/net/decnet/node_address

> # ls /proc/sys/net/decnet   <--- after writing to/proc/sys/net/decnet/node_address, all the static sysctl entries in /proc/sys/net/decnet are gone
> conf

> # ls /proc/sys/net/decnet/conf   <--- so are all the static sysctl entries in /proc/sys/net/decnet/conf (because only the dynamic entries have been reregistered)
> eth0  lo

DIAGNOSIS

I found that the disappearance of the decnet /proc/sys/net/decnet sysctl entries coincided with a change in the sysctl subsystem from using a list to a tree for the ctl_table data structures.  I corresponded with Eric Biederman, the maintainer of sysctl, and described the change in behavior and my diagnosis that the sysctl changes were suspect.  Eric described what was likely the source of the problem:

> Looking into the git history it looks like the last substantive change
> to 2.6.32 was Al Viro's sysctl optimization that avoided walking the
> entire sysctl structure on look ups.  Unfortunately it made the
> assumption that there would always be an empty directory created if
> there were multiple children registered in that that directory.  The
> common sysctls the few places this wasn't true were fixed rather
> quickly.  Apparently for decnet no one noticed.
> 
> The good news is that my latest rework of the sysctls made a verifiable
> set of assumptions.  So it will probably just work although there is a
> slight chance the modern code will error out with sensible error
> message.


SOLUTION

Eric was also kind enough to verify that his later rewrite of the sysctl code cured the problem:

> My rewrite to remove the silly assumption
> and to make sysctl even more scalable was merged in 3.4-rc1.  So
> anything 3.4 based or later should work.

and

> I have confirmed in the lastest kernel I can set the decnet node address
> without all of the sysctl files going away.  So it looks like I fixed
> the bug you are running into.


PATCHES

I still care about running DECnet on CentOS and Arch Linux ARM.  Following Eric's guidance, I rearranged the order that the /proc/sys/net/decnet sysctl entries are created and I added an empty /proc/sys/net/decnet/conf sysctl entry to workaround the sysctl tree walking bug.  I made three sets of patches that cover the changes to the sysctl API over time:

. Kernels 2.6.27 through 2.6.32 (tree-structured sysctl, struct ctl_path includes .ctl_name) - e.g., for the current CentOS (Red Hat)
. Kernels 2.6.33 through 3.4.x (struct ctl_path no longer includes .ctl_name, rtnl_register() adds rtnl_calcit_func calcit) - e.g., for the current Arch Linux ARM
. Kernels 3.5 and later (register_net_sysctl()/unregister_net_sysctl_table() in place of register_sysctl_paths()/unregister_sysctl_table()) - for the current trunk

As I described in my earlier post (11 February 2013 4:26:00 PM PST), my patches include more than just this fix, so they are not yet ready to submit.  However, I am using the first two in my application systems, so I am confident they work and there is no need for anyone else to work on a fix.

My questions for this forum are:

. Which patches (if any) should be submitted to netdev@vger.kernel.org?
. Which patches (if any) should be submitted to stable@vger.kernel.org?
. Should I prepare be a patch file for every kernel major.minor version?
. If not, which kernel major.minor versions should I create a patch file for?
. How should they be labeled to indicate they are related but distinct?
. The decnet dmesg banner is stale -- it has not changed in years.  Should that be changed?  To what?  What's the numbering scheme?  By me?  By the maintainer?

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Re: decnet: /proc/sys/net/decnet sysctl entries disappear

[Larry Baker]

Eric,

(Sorry for the re-send.  I had to make up a new e-mail address book entry for you without your middle initial to pass through the vger.kernel.org e-mail filters.  Apple Mail shows me the enclosing quotes, but apparently doesn't actually insert them in the SMTP text.)

FYI.  My original post to netdev for this problem is at http://www.spinics.net/lists/netdev/msg225990.html.  Since then, I have focused on reporting and patching only the problem with the disappearing sysctl entries.  My follow-up post with the problem description is at http://www.spinics.net/lists/netdev/msg226123.html.

On 13 Feb 2013, at 1:01 AM, Eric W. Biederman wrote:

> If you send me just the sysctl bits I will be happy to
> double check them and forward them to stable@vger.kernel.org.  Feel free
> to Cc netdev.  For at least the sysctl bits having them pass through me
> and getting my quick review and signed-off-by should help a little
> getting them backported.

Below is my stab at a proper patch for this problem for the 2.6.32.60 stable kernel.  This is the kernel series used by the latest CentOS/Red Hat 6.3.

scripts/checkpatch.pl warns about a couple lines over 80 characters (code motion and the banner), and gives one error:

ERROR: do not initialise statics to 0 or NULL
#53: FILE: net/decnet/dn_dev.c:173:
+static struct ctl_table_header *dn_conf_path = NULL;

I followed the same practice as the code in net/decnet/sysctl_net_decnet.c:

static struct ctl_table_header *dn_table_header = NULL;

I leave it to you to decide if that is a concern.

> For your other changes I can't tell if they are clean-ups or enhancments
> or just unneeded (like updating the banner string). As a cleanup it
> would probably make sense to just delete that silly banner string.

Lots of kernel modules have banner strings.  I find them informative.  I think the version should to be updated when (substantive?) changes are made.

> There are question I have when looking at your patches:
> Does dn_hiord_addr to -> dh_hiord make a difference?
> What is the purpose of all of the code motion?
> Will anyone besides you use the new debug option?  Or would we better to
> just forget that change.

Maybe only your code motion question still applies?  The code motion is required to create the sysctl entries in the correct order:

. Static executor node (host) entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template network device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active DECnet device entries in /proc/sys/net/decnet/conf/<dev-name>

The entries in /proc/sys/net/decnet are created in sysctl_net_decnet.c; the entries in /proc/sys/net/decnet/conf are created in dn_dev.c.  The workaround only works when the empty path entry is created before the entries in /proc/sys/net/decnet.  Thus the code rearrangement.  Even when the workaround can be removed (3.4 and later), I think this is more rational behavior.

> Eric

Thanks again,

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

----------

This is the patch for stable kernel 2.6.32.60.  I tested this on a CentOS 6.3 x86_64 system, which uses a 2.6.32+ kernel.  I installed the 2.6.32.60 kernel, verified the problem in the original decnet module, patched the decnet source, and verified the patched module fixes the problem.

I don't know what is a good subject line.  It is supposed to say "what" and "why".  Should it tie in to the same patches Al made for net/core and net/ipv6?  (Add a reference to those patches in the message body?)  Should it mention the aberrant behavior being fixed?

I tried to pay attention to separating the lines for the changelog from the rest of the description.

Subject line:

Subject: [PATCH] decnet: Fix for sysctl rewrite (stable kernel 2.6.32.x)

Message body:

From: Larry Baker <baker@usgs.gov>

Fixes the problem of disappearing /proc/sys/net/decnet sysctl entries reported in http://www.spinics.net/lists/netdev/msg226123.html.  Applies the same workaround used in net/core/sysctl_net_core.c and net/ipv6/sysctl_net_ipv6.c.

The problem first appeared in kernel 2.6.27.  The later rewrite of sysctl in kernel 3.4 restored the previous behavior and eliminated the need for this workaround. 

Signed-off-by: Larry Baker <baker@usgs.gov>
---

The workaround is to register an empty sysctl path entry before registering any entries beneath it.  For example, the same workaround appears in sysctl_core_init() in net/core/sysctl_net_core.c and ipv6_static_sysctl_register() in net/ipv6/sysctl_net_ipv6.c.

The additional code motion is required to create the sysctl entries in the correct order:

. Static executor node (host) entries in /proc/sys/net/decnet
. Static empty path entry /proc/sys/net/decnet/conf
. Static template network device entries in /proc/sys/net/decnet/conf/<type>
. Dynamic active DECnet device entries in /proc/sys/net/decnet/conf/<dev-name>

The entries in /proc/sys/net/decnet are created in sysctl_net_decnet.c; the entries in /proc/sys/net/decnet/conf are created in dn_dev.c.  The workaround only works when the empty path entry is created before the entries in /proc/sys/net/decnet.  The code rearrangement accomplishes this.

--- original/net/decnet/af_decnet.c
+++ patched/net/decnet/af_decnet.c
@@ -2360,7 +2360,7 @@ MODULE_AUTHOR("Linux DECnet Project Team
MODULE_LICENSE("GPL");
MODULE_ALIAS_NETPROTO(PF_DECnet);

-static char banner[] __initdata = KERN_INFO "NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team\n";
+static char banner[] __initdata = KERN_INFO "DECnet: DECnet for Linux: V.2.6.32 (C) 1995-2013 Linux DECnet Project Team\n";

static int __init decnet_init(void)
{
@@ -2372,6 +2372,8 @@ static int __init decnet_init(void)
	if (rc != 0)
		goto out;

+	dn_register_sysctl();
+
	dn_neigh_init();
	dn_dev_init();
	dn_route_init();
@@ -2382,7 +2384,6 @@ static int __init decnet_init(void)
	register_netdevice_notifier(&dn_dev_notifier);

	proc_net_fops_create(&init_net, "decnet", S_IRUGO, &dn_socket_seq_fops);
-	dn_register_sysctl();
out:
	return rc;

@@ -2401,8 +2402,6 @@ static void __exit decnet_exit(void)
	rtnl_unregister_all(PF_DECnet);
	dev_remove_pack(&dn_dix_packet_type);

-	dn_unregister_sysctl();
-
	unregister_netdevice_notifier(&dn_dev_notifier);

	dn_route_cleanup();
@@ -2410,6 +2409,8 @@ static void __exit decnet_exit(void)
	dn_neigh_cleanup();
	dn_fib_cleanup();

+	dn_unregister_sysctl();
+
	proc_net_remove(&init_net, "decnet");

	proto_unregister(&dn_proto);
--- original/net/decnet/dn_dev.c
+++ patched/net/decnet/dn_dev.c
@@ -170,6 +170,8 @@ static int dn_forwarding_sysctl(ctl_tabl
			void __user *oldval, size_t __user *oldlenp,
			void __user *newval, size_t newlen);

+static struct ctl_table_header *dn_conf_path = NULL;
+
static struct dn_dev_sysctl_table {
	struct ctl_table_header *sysctl_header;
	ctl_table dn_dev_vars[5];
@@ -1436,6 +1438,14 @@ MODULE_PARM_DESC(addr, "The DECnet addre

void __init dn_dev_init(void)
{
+	struct ctl_path dn_conf[] = {
+		{ .procname = "net", .ctl_name = CTL_NET, },
+		{ .procname = "decnet", .ctl_name = NET_DECNET, },
+		{ .procname = "conf", .ctl_name = NET_DECNET_CONF, },
+		{ },
+	};
+	static ctl_table empty[1];
+
	if (addr[0] > 63 || addr[0] < 0) {
		printk(KERN_ERR "DECnet: Area must be between 0 and 63");
		return;
@@ -1448,34 +1458,36 @@ void __init dn_dev_init(void)

	decnet_address = cpu_to_le16((addr[0] << 10) | addr[1]);

-	dn_dev_devices_on();
-
-	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL);
-	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL);
-	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr);
-
-	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
-
#ifdef CONFIG_SYSCTL
+	dn_conf_path = register_sysctl_paths(dn_conf, empty);
	{
		int i;
		for(i = 0; i < DN_DEV_LIST_SIZE; i++)
			dn_dev_sysctl_register(NULL, &dn_dev_list[i]);
	}
#endif /* CONFIG_SYSCTL */
+
+	dn_dev_devices_on();
+
+	rtnl_register(PF_DECnet, RTM_NEWADDR, dn_nl_newaddr, NULL);
+	rtnl_register(PF_DECnet, RTM_DELADDR, dn_nl_deladdr, NULL);
+	rtnl_register(PF_DECnet, RTM_GETADDR, NULL, dn_nl_dump_ifaddr);
+
+	proc_net_fops_create(&init_net, "decnet_dev", S_IRUGO, &dn_dev_seq_fops);
}

void __exit dn_dev_cleanup(void)
{
+	proc_net_remove(&init_net, "decnet_dev");
+
+	dn_dev_devices_off();
+
#ifdef CONFIG_SYSCTL
	{
		int i;
		for(i = 0; i < DN_DEV_LIST_SIZE; i++)
			dn_dev_sysctl_unregister(&dn_dev_list[i]);
	}
+	unregister_sysctl_table(dn_conf_path);
#endif /* CONFIG_SYSCTL */
-
-	proc_net_remove(&init_net, "decnet_dev");
-
-	dn_dev_devices_off();
}