[v2] net: Allow class-e address assignment via ifconfig ioctl

Message ID 20190214131604.8107-1-linus.walleij@linaro.org
State New
Headers show
Series
  • [v2] net: Allow class-e address assignment via ifconfig ioctl
Related show

Commit Message

Linus Walleij Feb. 14, 2019, 1:16 p.m.
From: Dave Taht <dave.taht@gmail.com>


commit 65cab850f0eeaa9180bd2e10a231964f33743edf upstream.

While most distributions long ago switched to the iproute2 suite
of utilities, which allow class-e (240.0.0.0/4) address assignment,
distributions relying on busybox, toybox and other forms of
ifconfig cannot assign class-e addresses without this kernel patch.

While CIDR has been obsolete for 2 decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.

Signed-off-by: Dave Taht <dave.taht@gmail.com>

Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

---
ChangeLog v1->v2:
- Add SoB-line

- This commit is upstream in v4.20
- This should ve applied for stable v4.19.y, v4.14.y and v4.9.y
---
 include/uapi/linux/in.h | 10 +++++++---
 net/ipv4/devinet.c      |  5 +++--
 net/ipv4/ipconfig.c     |  2 ++
 3 files changed, 12 insertions(+), 5 deletions(-)

-- 
2.20.1

Comments

Sasha Levin Feb. 17, 2019, 6:22 p.m. | #1
On Thu, Feb 14, 2019 at 02:16:04PM +0100, Linus Walleij wrote:
>From: Dave Taht <dave.taht@gmail.com>

>

>commit 65cab850f0eeaa9180bd2e10a231964f33743edf upstream.

>

>While most distributions long ago switched to the iproute2 suite

>of utilities, which allow class-e (240.0.0.0/4) address assignment,

>distributions relying on busybox, toybox and other forms of

>ifconfig cannot assign class-e addresses without this kernel patch.

>

>While CIDR has been obsolete for 2 decades, and a survey of all the

>open source code in the world shows the IN_whatever macros are also

>obsolete... rather than obsolete CIDR from this ioctl entirely, this

>patch merely enables class-e assignment, sanely.

>

>Signed-off-by: Dave Taht <dave.taht@gmail.com>

>Signed-off-by: David S. Miller <davem@davemloft.net>

>Signed-off-by: Linus Walleij <linus.walleij@linaro.org>


Is this really a fix? This isn't something that ever worked.

Either way, David Miller will need to sign off on this since he manages
net/ -stable patches.

--
Thanks,
Sasha
Linus Walleij Feb. 17, 2019, 9:18 p.m. | #2
On Sun, Feb 17, 2019 at 7:22 PM Sasha Levin <sashal@kernel.org> wrote:
> On Thu, Feb 14, 2019 at 02:16:04PM +0100, Linus Walleij wrote:

> >From: Dave Taht <dave.taht@gmail.com>

> >

> >commit 65cab850f0eeaa9180bd2e10a231964f33743edf upstream.

> >

> >While most distributions long ago switched to the iproute2 suite

> >of utilities, which allow class-e (240.0.0.0/4) address assignment,

> >distributions relying on busybox, toybox and other forms of

> >ifconfig cannot assign class-e addresses without this kernel patch.

> >

> >While CIDR has been obsolete for 2 decades, and a survey of all the

> >open source code in the world shows the IN_whatever macros are also

> >obsolete... rather than obsolete CIDR from this ioctl entirely, this

> >patch merely enables class-e assignment, sanely.

> >

> >Signed-off-by: Dave Taht <dave.taht@gmail.com>

> >Signed-off-by: David S. Miller <davem@davemloft.net>

> >Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

>

> Is this really a fix? This isn't something that ever worked.


I guess it fits the bill of "a real bug that bothers people", what OpenWrt
wants is to use their simple userspace to set up class-e addresses
and without this patch, this doesn't work for them, and IIUC it could
be expected to work.

I guess it is an ontological question whether OpenWrt are "fixning"
or "stabilizing" or "adding features" by making class-e networks
work with good old ifconfig. The maintainer(s) will decide.

> Either way, David Miller will need to sign off on this since he manages

> net/ -stable patches.


I was unaware of different route points for stable patches, but it makes
sense.

Maybe we should add some kind of tagging
entries to MAINTAINERS so it is clear where to route stable
material? Right now I guess it is another one of these undocumented
rules that one is supposed to pick up by first annoying everyone :D

Are there other subsystems that have a second-level maintainer
for stable, so I know before annoying someone else?

Yours,
Linus Walleij
David Miller Feb. 17, 2019, 9:49 p.m. | #3
From: Sasha Levin <sashal@kernel.org>

Date: Sun, 17 Feb 2019 13:22:41 -0500

> On Thu, Feb 14, 2019 at 02:16:04PM +0100, Linus Walleij wrote:

>>From: Dave Taht <dave.taht@gmail.com>

>>

>>commit 65cab850f0eeaa9180bd2e10a231964f33743edf upstream.

>>

>>While most distributions long ago switched to the iproute2 suite

>>of utilities, which allow class-e (240.0.0.0/4) address assignment,

>>distributions relying on busybox, toybox and other forms of

>>ifconfig cannot assign class-e addresses without this kernel patch.

>>

>>While CIDR has been obsolete for 2 decades, and a survey of all the

>>open source code in the world shows the IN_whatever macros are also

>>obsolete... rather than obsolete CIDR from this ioctl entirely, this

>>patch merely enables class-e assignment, sanely.

>>

>>Signed-off-by: Dave Taht <dave.taht@gmail.com>

>>Signed-off-by: David S. Miller <davem@davemloft.net>

>>Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

> 

> Is this really a fix? This isn't something that ever worked.

> 

> Either way, David Miller will need to sign off on this since he

> manages

> net/ -stable patches.


I don't think this is -stable material at all.
Sasha Levin Feb. 17, 2019, 11:08 p.m. | #4
On Sun, Feb 17, 2019 at 10:18:29PM +0100, Linus Walleij wrote:
>On Sun, Feb 17, 2019 at 7:22 PM Sasha Levin <sashal@kernel.org> wrote:

>> Either way, David Miller will need to sign off on this since he manages

>> net/ -stable patches.

>

>I was unaware of different route points for stable patches, but it makes

>sense.

>

>Maybe we should add some kind of tagging

>entries to MAINTAINERS so it is clear where to route stable

>material? Right now I guess it is another one of these undocumented

>rules that one is supposed to pick up by first annoying everyone :D

>

>Are there other subsystems that have a second-level maintainer

>for stable, so I know before annoying someone else?


I really think that this is the only exception to the procees, and given
that David is only looking at the last 2 -stable releases (that would be
4.20 and 4.19 right now) it gets a bit tricky for folks who are not
intimate with the process. So no, you're not annoying anyone :)

FWIW, the process is documented here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n134

--
Thanks,
Sasha

Patch

diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
index 48e8a225b985..f6052e70bf40 100644
--- a/include/uapi/linux/in.h
+++ b/include/uapi/linux/in.h
@@ -266,10 +266,14 @@  struct sockaddr_in {
 
 #define	IN_CLASSD(a)		((((long int) (a)) & 0xf0000000) == 0xe0000000)
 #define	IN_MULTICAST(a)		IN_CLASSD(a)
-#define IN_MULTICAST_NET	0xF0000000
+#define	IN_MULTICAST_NET	0xe0000000
 
-#define	IN_EXPERIMENTAL(a)	((((long int) (a)) & 0xf0000000) == 0xf0000000)
-#define	IN_BADCLASS(a)		IN_EXPERIMENTAL((a))
+#define	IN_BADCLASS(a)		((((long int) (a) ) == 0xffffffff)
+#define	IN_EXPERIMENTAL(a)	IN_BADCLASS((a))
+
+#define	IN_CLASSE(a)		((((long int) (a)) & 0xf0000000) == 0xf0000000)
+#define	IN_CLASSE_NET		0xffffffff
+#define	IN_CLASSE_NSHIFT	0
 
 /* Address to accept any incoming messages. */
 #define	INADDR_ANY		((unsigned long int) 0x00000000)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ea4bd8a52422..e38042933a27 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -941,17 +941,18 @@  static int inet_abc_len(__be32 addr)
 {
 	int rc = -1;	/* Something else, probably a multicast. */
 
-	if (ipv4_is_zeronet(addr))
+	if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
 		rc = 0;
 	else {
 		__u32 haddr = ntohl(addr);
-
 		if (IN_CLASSA(haddr))
 			rc = 8;
 		else if (IN_CLASSB(haddr))
 			rc = 16;
 		else if (IN_CLASSC(haddr))
 			rc = 24;
+		else if (IN_CLASSE(haddr))
+			rc = 32;
 	}
 
 	return rc;
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 88212615bf4c..2393e5c106bf 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -429,6 +429,8 @@  static int __init ic_defaults(void)
 			ic_netmask = htonl(IN_CLASSB_NET);
 		else if (IN_CLASSC(ntohl(ic_myaddr)))
 			ic_netmask = htonl(IN_CLASSC_NET);
+		else if (IN_CLASSE(ntohl(ic_myaddr)))
+			ic_netmask = htonl(IN_CLASSE_NET);
 		else {
 			pr_err("IP-Config: Unable to guess netmask for address %pI4\n",
 			       &ic_myaddr);