net: add dev_loopback_xmit() to avoid duplicate code
Subsystems (3)
PATCH 1/1 net: add dev_loopback_xmit() to avoid duplicate code
Add dev_loopback_xmit() in order to deduplicate functions ip_dev_loopback_xmit() (in net/ipv4/ip_output.c) and ip6_dev_loopback_xmit() (in net/ipv6/ip6_output.c).
I was about to reinvent the wheel when I noticed that ip_dev_loopback_xmit() and ip6_dev_loopback_xmit() do exactly what I need and are not IP-only functions, but they were not available to reuse elsewhere.
ip6_dev_loopback_xmit() does not have line "skb_dst_force(skb);", but I understand that this is harmless, and should be be in dev_loopback_xmit().
---
include/linux/netdevice.h +1 -0
@@ -1626,6 +1626,7 @@ extern int dev_alloc_name(struct net_device *dev, const char *name);extern int dev_open (struct net_device *dev);extern int dev_close (struct net_device *dev);extern void dev_disable_lro (struct net_device *dev); +extern int dev_loopback_xmit (struct sk_buff *newskb);extern int dev_queue_xmit (struct sk_buff *skb);extern int register_netdevice (struct net_device *dev); extern void unregister_netdevice_queue(struct net_device *dev,
net/core/dev.c +17 -0
@@ -2476,6 +2476,23 @@ static DEFINE_PER_CPU(int, xmit_recursion);#define RECURSION_LIMIT 10/** +* dev_loopback_xmit - loop back @skb +* @skb: buffer to transmit +*/ +int dev_loopback_xmit (struct sk_buff *skb) +{ +skb_reset_mac_header (skb); +__skb_pull (skb,skb_network_offset (skb)); + skb->pkt_type =PACKET_LOOPBACK ; + skb->ip_summed =CHECKSUM_UNNECESSARY ; +WARN_ON (!skb_dst (skb)); +skb_dst_force (skb); +netif_rx_ni (skb); +return 0 ; +} +EXPORT_SYMBOL (dev_loopback_xmit); + +/** * dev_queue_xmit - transmit a buffer * @skb: buffer to transmit *
net/ipv4/ip_output.c +2 -15
@@ -113,19 +113,6 @@ int ip_local_out(struct sk_buff *skb) }EXPORT_SYMBOL_GPL (ip_local_out); -/* dev_loopback_xmit for use with netfilter. */ -static int ip_dev_loopback_xmit (struct sk_buff *newskb) -{ -skb_reset_mac_header (newskb); -__skb_pull (newskb,skb_network_offset (newskb)); - newskb->pkt_type =PACKET_LOOPBACK ; - newskb->ip_summed =CHECKSUM_UNNECESSARY ; -WARN_ON (!skb_dst (newskb)); -skb_dst_force (newskb); -netif_rx_ni (newskb); -return 0 ; -} -static inline int ip_select_ttl (struct inet_sock *inet,struct dst_entry *dst) {int ttl = inet->uc_ttl;
@@ -281,7 +268,7 @@ int ip_mc_output(struct sk_buff *skb)if (newskb)NF_HOOK (NFPROTO_IPV4 ,NF_INET_POST_ROUTING , newskb,NULL , newskb->dev, - ip_dev_loopback_xmit); + dev_loopback_xmit); }/* Multicasts with ttl 0 must not go beyond the host */
@@ -296,7 +283,7 @@ int ip_mc_output(struct sk_buff *skb)struct sk_buff *newskb =skb_clone (skb,GFP_ATOMIC );if (newskb)NF_HOOK (NFPROTO_IPV4 ,NF_INET_POST_ROUTING , newskb, -NULL , newskb->dev, ip_dev_loopback_xmit); +NULL , newskb->dev, dev_loopback_xmit); } return NF_HOOK_COND(NFPROTO_IPV4, NF_INET_POST_ROUTING, skb, NULL,
net/ipv6/ip6_output.c +1 -14
@@ -83,19 +83,6 @@ int ip6_local_out(struct sk_buff *skb) }EXPORT_SYMBOL_GPL (ip6_local_out); -/* dev_loopback_xmit for use with netfilter. */ -static int ip6_dev_loopback_xmit (struct sk_buff *newskb) -{ -skb_reset_mac_header (newskb); -__skb_pull (newskb,skb_network_offset (newskb)); - newskb->pkt_type =PACKET_LOOPBACK ; - newskb->ip_summed =CHECKSUM_UNNECESSARY ; -WARN_ON (!skb_dst (newskb)); - -netif_rx_ni (newskb); -return 0 ; -} -static int ip6_finish_output2 (struct sk_buff *skb) {struct dst_entry *dst =skb_dst (skb);
@@ -121,7 +108,7 @@ static int ip6_finish_output2(struct sk_buff *skb)if (newskb)NF_HOOK (NFPROTO_IPV6 ,NF_INET_POST_ROUTING , newskb,NULL , newskb->dev, - ip6_dev_loopback_xmit); + dev_loopback_xmit);if (ipv6_hdr (skb)->hop_limit ==0 ) { IP6_INC_STATS(dev_net(dev), idev,
David Miller
maintainerI'm getting really tired of saying this.
As I announced several days ago, it is absolutely not appropriate to submit patches other than bug fixes at this time because we are in the merge window and the net-next tree is frozen.
And even once I do announce here that the net-next tree is open once more, and patches like this one are appropriate, you must indicate in the subject line which of the 'net' or 'net-next' tree you are targetting your patch at.
Please pay attention to what's going on, and what state the networking development trees are in, before submitting changes.
Quoted 6 lines
I'm getting really tired of saying this.
As I announced several days ago, it is absolutely not appropriate to submit patches other than bug fixes at this time because we are in the merge window and the net-next tree is frozen.
Quoted 7 lines
And even once I do announce here that the net-next tree is open once more, and patches like this one are appropriate, you must indicate in the subject line which of the 'net' or 'net-next' tree you are targetting your patch at.
Please pay attention to what's going on, and what state the networking development trees are in, before submitting changes.
I am sorry. I'm still new to this process, and I clearly haven't found my way yet. Accept my apology and consider that others making the same mistake are likely trying to find their ways as well. Rest sure that I do appreciate your time and work, I'll pay more attention on those time windows.
Just to avoid bothering you further, should I resend this patch or not? I saw at the link below that it's already marked as "Deferred".
http://patchwork.ozlabs.org/patch/160929/
Is there a link where I can check the state (i.e. open, frozen) of 'net' and 'net-next' trees? I think keeping such page, and adding this link to Documentation/SubmittingPatches would reduce similar mistakes.
Signature · 2 lines
[ ]'s Michel Machado
David Miller
maintainerFrom: Michel Machado <[email protected]>
Date: Tue, 05 Jun 2012 09:23:33 -0400
Quoted 1 line
Just to avoid bothering you further, should I resend this patch or not?
Always resend patches.