Skip to contentSkip to conversation

ip_tunnel: Ops registration for secondary encap (fou, gue)

PATCH Applied Tom Herbert 2 participants 4 messages Nov 12, 2014

Subsystems (3)
Networking Network drivers IPv4/IPv6
lore
Share & tools
lore

Tom Herbert

author
#0 lore raw

PATCH 1/1 ip_tunnel: Ops registration for secondary encap (fou, gue)

Instead of calling fou and gue functions directly from ip_tunnel use ops for these that were previously registered. This patch adds the logic to add and remove encapsulation operations for ip_tunnel, and modified fou (and gue) to register with ip_tunnels.

This patch also addresses a circular dependency between ip_tunnel and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y and CONFIG_NET_FOU=m. References to fou an gue have been removed from ip_tunnel.c

Reported-by Randy Dunlap <[email protected]>
Signed-off-by Tom Herbert <[email protected]>
---
 include/net/fou.h        | 25 ++------------
 include/net/ip_tunnels.h | 16 +++++++++
 net/ipv4/fou.c           | 85 ++++++++++++++++++++++++++++++++++++++++++++++++
 net/ipv4/ip_tunnel.c     | 78 ++++++++++++++++++++++++++++++--------------
 4 files changed, 157 insertions(+), 47 deletions(-)
include/net/fou.h +3 -22
index 25b26ff..19b8a0c 100644
@@ -8,31 +8,12 @@
 #include <net/ip_tunnels.h>
 #include <net/udp.h>
 
+size_t fou_encap_hlen(struct ip_tunnel_encap *e);
+static size_t gue_encap_hlen(struct ip_tunnel_encap *e);
+
 int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
 		     u8 *protocol, struct flowi4 *fl4);
 int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
 		     u8 *protocol, struct flowi4 *fl4);
 
-static size_t fou_encap_hlen(struct ip_tunnel_encap *e)
-{
-	return sizeof(struct udphdr);
-}
-
-static size_t gue_encap_hlen(struct ip_tunnel_encap *e)
-{
-	size_t len;
-	bool need_priv = false;
-
-	len = sizeof(struct udphdr) + sizeof(struct guehdr);
-
-	if (e->flags & TUNNEL_ENCAP_FLAG_REMCSUM) {
-		len += GUE_PLEN_REMCSUM;
-		need_priv = true;
-	}
-
-	len += need_priv ? GUE_LEN_PRIV : 0;
-
-	return len;
-}
-
 #endif
include/net/ip_tunnels.h +16 -0
index 5bc6ede..25a59eb 100644
@@ -117,6 +117,22 @@ struct ip_tunnel_net {
 	struct hlist_head tunnels[IP_TNL_HASH_SIZE];
 };
 
+struct ip_tunnel_encap_ops {
+	size_t (*encap_hlen)(struct ip_tunnel_encap *e);
+	int (*build_header)(struct sk_buff *skb, struct ip_tunnel_encap *e,
+			    u8 *protocol, struct flowi4 *fl4);
+};
+
+#define MAX_IPTUN_ENCAP_OPS 8
+
+extern const struct ip_tunnel_encap_ops __rcu *
+		iptun_encaps[MAX_IPTUN_ENCAP_OPS];
+
+int ip_tunnel_encap_add_ops(const struct ip_tunnel_encap_ops *op,
+			    unsigned int num);
+int ip_tunnel_encap_del_ops(const struct ip_tunnel_encap_ops *op,
+			    unsigned int num);
+
 #ifdef CONFIG_INET
 
 int ip_tunnel_init(struct net_device *dev);
net/ipv4/fou.c +85 -0

109 lines not on this page · raw message

net/ipv4/ip_tunnel.c +53 -25

100 lines not on this page · raw message

Signature · 1 line
2.1.0.rc2.206.gedb03e5
maintainer Applied
#1 lore raw

From: Tom Herbert <[email protected]>
Date: Wed, 12 Nov 2014 11:54:09 -0800

Quoted 5 lines

Instead of calling fou and gue functions directly from ip_tunnel use ops for these that were previously registered. This patch adds the logic to add and remove encapsulation operations for ip_tunnel, and modified fou (and gue) to register with ip_tunnels.

Quoted 7 lines

This patch also addresses a circular dependency between ip_tunnel and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y and CONFIG_NET_FOU=m. References to fou an gue have been removed from ip_tunnel.c

Reported-by Randy Dunlap <[email protected]>
Signed-off-by Tom Herbert <[email protected]>

Applied, please in the future be explicit about the target tree by saying "[PATCH net-next]" or similar in your Subj.

I'm pretty sure this isn't the first time I've had to ask this of you. :-/

Thanks Tom.

author
#2 lore raw
Quoted 13 lines · David Miller

From: Tom Herbert <[email protected]>
Date: Wed, 12 Nov 2014 11:54:09 -0800

Quoted 10 lines

Instead of calling fou and gue functions directly from ip_tunnel use ops for these that were previously registered. This patch adds the logic to add and remove encapsulation operations for ip_tunnel, and modified fou (and gue) to register with ip_tunnels.

This patch also addresses a circular dependency between ip_tunnel and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y and CONFIG_NET_FOU=m. References to fou an gue have been removed from ip_tunnel.c

Quoted 9 lines
Quoted 2 lines
Reported-by Randy Dunlap <[email protected]>
Signed-off-by Tom Herbert <[email protected]>

Applied, please in the future be explicit about the target tree by saying "[PATCH net-next]" or similar in your Subj.

I'm pretty sure this isn't the first time I've had to ask this of you. :-/

I was unsure which branch to target since the bug was reported in linux-next. Is next-next appropriate in this case?

Thanks,
Tom

Quoted 1 line

Thanks Tom.

maintainer
#3 lore raw

From: Tom Herbert <[email protected]>
Date: Wed, 12 Nov 2014 12:07:19 -0800

Quoted 17 lines · David Miller
Quoted 16 lines

From: Tom Herbert <[email protected]>
Date: Wed, 12 Nov 2014 11:54:09 -0800

Quoted 12 lines

Instead of calling fou and gue functions directly from ip_tunnel use ops for these that were previously registered. This patch adds the logic to add and remove encapsulation operations for ip_tunnel, and modified fou (and gue) to register with ip_tunnels.

This patch also addresses a circular dependency between ip_tunnel and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y and CONFIG_NET_FOU=m. References to fou an gue have been removed from ip_tunnel.c

Reported-by Randy Dunlap <[email protected]>
Signed-off-by Tom Herbert <[email protected]>
Quoted 8 lines
Quoted 6 lines

Applied, please in the future be explicit about the target tree by saying "[PATCH net-next]" or similar in your Subj.

I'm pretty sure this isn't the first time I've had to ask this of you. :-/

I was unsure which branch to target since the bug was reported in linux-next. Is next-next appropriate in this case?

Tom, this code doesn't even exist in the 'net' tree, how could it possibly apply to anything other than 'net-next'?