Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Julian Anastasov writes: > Hello, > > On Thu, 18 Jun 2015, Eric W. Biederman wrote: > >> My incremental patch for ipvs on top of everything else I have pushed >> out looks like this: >> >> From: "Eric W. Biederman" >> Date: Fri, 12 Jun 2015 18:34:12 -0500 >> Subject: [PATCH] ipvs: Pass struct net down to where it is needed and used >> >> Pass struct net down to where it is used and stop guessing >> which network namespace should be used. > > At first look patch is ok. But I'm not sure > for the changes in ip_vs_xmit.c. Can you explain in > 2-3 lines, when can we see different netns? Is it when > packet is forwarded to output device and it is part from > another netns? > > I'm asking because these __ip_vs_get_out_rt* > calls in ip_vs_xmit.c can reroute packet to another > device... The driver was ensure_mtu_is_adequate where in one half of the function we have skb_net another half we have dev_net(dst_skb(skb)->dev).That is goofy. That gets replaced by ip_vs_conn_net(cp). In practice today I don't see that there are differences in network namespaces today. Moving forward I hope to be able to route packets out to network devices in different network namespaces. It is a massive optimization that doesn't need much code to support. Once that optimization is in place deriving the network namespace from the output device will not work. I believe using ip_vs_conn_net(cp) is a simple rule that is easy to understand and easy to implement correctly on the output path. > Also, skb_sknet is another candidate for removal. > But I can take care about it after your changes are > pushed... *nod* Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Hello, On Thu, 18 Jun 2015, Eric W. Biederman wrote: > My incremental patch for ipvs on top of everything else I have pushed > out looks like this: > > From: "Eric W. Biederman" > Date: Fri, 12 Jun 2015 18:34:12 -0500 > Subject: [PATCH] ipvs: Pass struct net down to where it is needed and used > > Pass struct net down to where it is used and stop guessing > which network namespace should be used. At first look patch is ok. But I'm not sure for the changes in ip_vs_xmit.c. Can you explain in 2-3 lines, when can we see different netns? Is it when packet is forwarded to output device and it is part from another netns? I'm asking because these __ip_vs_get_out_rt* calls in ip_vs_xmit.c can reroute packet to another device... Also, skb_sknet is another candidate for removal. But I can take care about it after your changes are pushed... Regards -- Julian Anastasov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Cc' list trimmed as this is not longer about the original patch
submission.
Julian Anastasov writes:
> Hello,
>
> On Wed, 17 Jun 2015, Eric W. Biederman wrote:
>
>> p.s. I do have my patch that I can toss in your direction if you are
>> interested.
>
> Of course... I'll be able to check it after 8 hours...
My incremental patch for ipvs on top of everything else I have pushed
out looks like this:
From: "Eric W. Biederman"
Date: Fri, 12 Jun 2015 18:34:12 -0500
Subject: [PATCH] ipvs: Pass struct net down to where it is needed and used
Pass struct net down to where it is used and stop guessing
which network namespace should be used.
Signed-off-by: "Eric W. Biederman"
---
include/net/ip_vs.h | 45 +++-
net/netfilter/ipvs/ip_vs_conn.c | 11 ++-
net/netfilter/ipvs/ip_vs_core.c | 118 ++--
net/netfilter/ipvs/ip_vs_ftp.c | 8 +--
net/netfilter/ipvs/ip_vs_proto_ah_esp.c | 9 ++-
net/netfilter/ipvs/ip_vs_proto_sctp.c | 5 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c| 8 +--
net/netfilter/ipvs/ip_vs_proto_udp.c| 5 +-
net/netfilter/ipvs/ip_vs_xmit.c | 51 --
net/netfilter/xt_ipvs.c | 2 +-
10 files changed, 108 insertions(+), 154 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 4e3731ee4eac..a556d14cff70 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -35,37 +35,6 @@ static inline struct netns_ipvs *net_ipvs(struct net* net)
return net->ipvs;
}
-/* Get net ptr from skb in traffic cases
- * use skb_sknet when call is from userland (ioctl or netlink)
- */
-static inline struct net *skb_net(const struct sk_buff *skb)
-{
-#ifdef CONFIG_NET_NS
-#ifdef CONFIG_IP_VS_DEBUG
- /*
-* This is used for debug only.
-* Start with the most likely hit
-* End with BUG
-*/
- if (likely(skb->dev && dev_net(skb->dev)))
- return dev_net(skb->dev);
- if (skb_dst(skb) && skb_dst(skb)->dev)
- return dev_net(skb_dst(skb)->dev);
- WARN(skb->sk, "Maybe skb_sknet should be used in %s() at line:%d\n",
- __func__, __LINE__);
- if (likely(skb->sk && sock_net(skb->sk)))
- return sock_net(skb->sk);
- pr_err("There is no net ptr to find in the skb in %s() line:%d\n",
- __func__, __LINE__);
- BUG();
-#else
- return dev_net(skb->dev ? : skb_dst(skb)->dev);
-#endif
-#else
- return &init_net;
-#endif
-}
-
static inline struct net *skb_sknet(const struct sk_buff *skb)
{
#ifdef CONFIG_NET_NS
@@ -441,19 +410,19 @@ struct ip_vs_protocol {
void (*exit_netns)(struct net *net, struct ip_vs_proto_data *pd);
- int (*conn_schedule)(int af, struct sk_buff *skb,
+ int (*conn_schedule)(struct net *net, int af, struct sk_buff *skb,
struct ip_vs_proto_data *pd,
int *verdict, struct ip_vs_conn **cpp,
struct ip_vs_iphdr *iph);
struct ip_vs_conn *
- (*conn_in_get)(int af,
+ (*conn_in_get)(struct net *net, int af,
const struct sk_buff *skb,
const struct ip_vs_iphdr *iph,
int inverse);
struct ip_vs_conn *
- (*conn_out_get)(int af,
+ (*conn_out_get)(struct net *net, int af,
const struct sk_buff *skb,
const struct ip_vs_iphdr *iph,
int inverse);
@@ -1179,13 +1148,15 @@ static inline void ip_vs_conn_fill_param(struct net
*net, int af, int protocol,
struct ip_vs_conn *ip_vs_conn_in_get(const struct ip_vs_conn_param *p);
struct ip_vs_conn *ip_vs_ct_in_get(const struct ip_vs_conn_param *p);
-struct ip_vs_conn * ip_vs_conn_in_get_proto(int af, const struct sk_buff *skb,
+struct ip_vs_conn * ip_vs_conn_in_get_proto(struct net *net, int af,
+ const struct sk_buff *skb,
const struct ip_vs_iphdr *iph,
int inverse);
struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p);
-struct ip_vs_conn * ip_vs_conn_out_get_proto(int af, const struct sk_buff *skb,
+struct ip_vs_conn * ip_vs_conn_out_get_proto(struct net *net, int af,
+const struct sk_buff *skb,
const struct ip_vs_iphdr *iph,
int inverse);
@@ -1215,7 +1186,7 @@ void ip_vs_conn_expire_now(struct ip_vs_conn *cp);
const char *ip_vs_state_name(__u16 proto, int state);
-void ip_vs_tcp_conn_listen(struct net *net, struct ip_vs_conn *cp);
+void ip_vs_tcp_conn_listen(struct ip_vs_conn *cp);
int ip_vs_check_template(struct ip_vs_conn *ct);
void ip_vs_random_dropentry(struct net *net);
int
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Hello, On Wed, 17 Jun 2015, Eric W. Biederman wrote: > p.s. I do have my patch that I can toss in your direction if you are > interested. Of course... I'll be able to check it after 8 hours... Regards -- Julian Anastasov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Julian Anastasov writes: > Hello, > > On Sun, 14 Jun 2015, Eric W. Biederman wrote: > >> This patshset roots out all of the very weird network namespace >> computation logic (except for the code in ipvs) and fixes it. I really >> don't like how the code has been essentially guessing which network >> namespace to use. >> >> Probably the worst guessing is in ipvs in the function skb_net. I have >> some preliminary changes to fix ipvs but they are not quite ready yet. >> Cleaning up ipvs enough that I can kill skb_net is on my short list. > > For IPVS skb_net is too complicated. One of > the first things we do in hook handler is to check > skb_dst, so even now dev_net(skb_dst(skb)->dev) should > work. A couple of things: - You don't check skb_dst() first thing in all hooks. - All hooks have state->net after my changes so it gets a lot easier. - I am trying to avoid dev_net(skb_dst(skb)->dev) if I can because of my ulterior motive of allowing a destination network device in another network namespace. > sock_net is used for administration via netlink, > skb_net is not used there (ip_vs_ctl.c). Agreed. sock_net is the right thing for the netlink sockets, and while obscured by skb_sknet that works fine. > As for removing/replacing skb_net, ip_vs_conn_net() > is ok when cp is present, Yes I have seen that. > we have also svc->net, And I have seen this. > otherwise > we can store net into struct ip_vs_iphdr, it is filled by > ip_vs_fill_iph_skb from small number of places when hook > handler is entered. Interesting I had not thought of changing ip_vs_iphdr. I actually have a patch that passes state->net down to where it is needed or uses ip_vs_conn_net() and it it looks ok, but the patch is so busy with small tweaks that I need to break it up. Further I am staring at things and trying to see if there is a way to make the mass of parameters more readable/obvious. Something like the passing of struct nf_hook_state into the netfilter hooks. Or in other words I want to make the change to ip_vs deadly boring, obviously correct, and trivial to maintain, and I am not quite there yet. Eric p.s. I do have my patch that I can toss in your direction if you are interested. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Hello, On Sun, 14 Jun 2015, Eric W. Biederman wrote: > This patshset roots out all of the very weird network namespace > computation logic (except for the code in ipvs) and fixes it. I really > don't like how the code has been essentially guessing which network > namespace to use. > > Probably the worst guessing is in ipvs in the function skb_net. I have > some preliminary changes to fix ipvs but they are not quite ready yet. > Cleaning up ipvs enough that I can kill skb_net is on my short list. For IPVS skb_net is too complicated. One of the first things we do in hook handler is to check skb_dst, so even now dev_net(skb_dst(skb)->dev) should work. sock_net is used for administration via netlink, skb_net is not used there (ip_vs_ctl.c). As for removing/replacing skb_net, ip_vs_conn_net() is ok when cp is present, we have also svc->net, otherwise we can store net into struct ip_vs_iphdr, it is filled by ip_vs_fill_iph_skb from small number of places when hook handler is entered. Regards -- Julian Anastasov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Pablo Neira Ayuso writes: > On Mon, Jun 15, 2015 at 07:26:13PM -0500, Eric W. Biederman wrote: > [...] >> So what I am in the processes of doing is reviewing and testing >> the combined set of patches and hopefully I will have something >> for you soon (tomorrow?). Unless Pablo has objections. > > Please, feel free to take over my patchset and improve it. That has > consumed part of my weekend and I have several open branches in my > internal tree that I need to push forward. > > So I'd be really happy if you polish them and get this done. > > Let me know if I can help in any case. Will do. I have found more bugs lurking in your boilter plate changes that I am comfortable with so I am in the process of refactoring things a bit more than you did so the sweeping changes are more pedantic and much less likely to introduce bugs. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
On Mon, Jun 15, 2015 at 07:26:13PM -0500, Eric W. Biederman wrote: [...] > So what I am in the processes of doing is reviewing and testing > the combined set of patches and hopefully I will have something > for you soon (tomorrow?). Unless Pablo has objections. Please, feel free to take over my patchset and improve it. That has consumed part of my weekend and I have several open branches in my internal tree that I need to push forward. So I'd be really happy if you polish them and get this done. Let me know if I can help in any case. Thanks a lot Eric. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 15 Jun 2015 19:26:13 -0500 > So what I am in the processes of doing is reviewing and testing > the combined set of patches and hopefully I will have something > for you soon (tomorrow?). Unless Pablo has objections. I will be travelling tomorrow so there is no rush. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Sun, 14 Jun 2015 22:07:30 -0500 > >> While looking into what it would take to route packets out to network >> devices in other network namespaces I started looking at the netfilter >> hooks, and there is a lot of nasty code to figure out which network >> namespace to filter the packets in. > > I am assume that you and Pablo are going to look at eachother's > work and decide how to proceed and therefore I'm getting another > series to actually apply at some point in the future. I am busily looking, and being slightly challenged by the fact that the netfilter code is a moving target in net-next. That is not really a bad thing as some of Pablo's patches were against the patches that were merged today. It does look like Pablo's path to getting per network namespace netfilter hooks is the best path to a good long term result, for per network namespace hooks. I am busily agumenting it with a Kconfig guard so bisection that disables network namespaces support while netfilter only works on the initial network namespace. As otherwise bisection will be a lost cause. AKA config NET_NS depends on !NETFILTER At the same time it looks like Pablos patches come out cleaner when rebased on my patchset. The number of conflicts between the two patchsets is very small and easily resolved. So what I am in the processes of doing is reviewing and testing the combined set of patches and hopefully I will have something for you soon (tomorrow?). Unless Pablo has objections. Right now I am attempting to verify that I have found all of the places in Pablo's patchset where the patches do not compile on their own, as there were some silly left-overs. But overall I think Pablo's patches look good. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
From: ebied...@xmission.com (Eric W. Biederman) Date: Sun, 14 Jun 2015 22:07:30 -0500 > While looking into what it would take to route packets out to network > devices in other network namespaces I started looking at the netfilter > hooks, and there is a lot of nasty code to figure out which network > namespace to filter the packets in. I am assume that you and Pablo are going to look at eachother's work and decide how to proceed and therefore I'm getting another series to actually apply at some point in the future. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
On Mon, Jun 15, 2015 at 10:06:27AM -0500, Eric W. Biederman wrote: > Pablo Neira Ayuso writes: > > > Hi Eric, > > > > On Sun, Jun 14, 2015 at 10:07:30PM -0500, Eric W. Biederman wrote: > >> > >> While looking into what it would take to route packets out to network > >> devices in other network namespaces I started looking at the netfilter > >> hooks, and there is a lot of nasty code to figure out which network > >> namespace to filter the packets in. > >> > >> Just passing the network namespace into the netfilter hooks looks like a > >> significant simplication in the code, and worth it as the first thing > >> most netfilter hooks do is compute the network namespace. > >> > >> We probably even want per network namespace netfilter hooks as nftables > >> tries (and fails to use). nftables currently has a fairly serious bug > >> where the tables for one network namespace run for packets in all > >> network namespaces. I do not have a fix yet but I think this patchset > >> making it easy to get at the network namespace is a good starting > >> place for a fix. > > > > I have a patchset that is almost ready to convert netfilter to pernet > > hooks, it partially clashes with this. Will send it out today and will > > Cc you so you can review it. > > > > I think it should take me little time to rebase it on top of yours. > > It's rather large changeset, which quite a lot of boiler plate code > > though. > > Hmm. > > I will wait and take a look. I think going from where I am to pernet > netfilter hooks is about one simple patch, so I don't know where the > large about of boiler plate comes from. You have to register the struct nf_hook_ops for each nf_register_hooks() caller from the pernet .init. > I think I will code that up so I can verify that and we can compare > notes later today. This is basically done here, I'll post this asap. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Pablo Neira Ayuso writes: > Hi Eric, > > On Sun, Jun 14, 2015 at 10:07:30PM -0500, Eric W. Biederman wrote: >> >> While looking into what it would take to route packets out to network >> devices in other network namespaces I started looking at the netfilter >> hooks, and there is a lot of nasty code to figure out which network >> namespace to filter the packets in. >> >> Just passing the network namespace into the netfilter hooks looks like a >> significant simplication in the code, and worth it as the first thing >> most netfilter hooks do is compute the network namespace. >> >> We probably even want per network namespace netfilter hooks as nftables >> tries (and fails to use). nftables currently has a fairly serious bug >> where the tables for one network namespace run for packets in all >> network namespaces. I do not have a fix yet but I think this patchset >> making it easy to get at the network namespace is a good starting >> place for a fix. > > I have a patchset that is almost ready to convert netfilter to pernet > hooks, it partially clashes with this. Will send it out today and will > Cc you so you can review it. > > I think it should take me little time to rebase it on top of yours. > It's rather large changeset, which quite a lot of boiler plate code > though. Hmm. I will wait and take a look. I think going from where I am to pernet netfilter hooks is about one simple patch, so I don't know where the large about of boiler plate comes from. I think I will code that up so I can verify that and we can compare notes later today. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/15] Simplify netfilter and network namespaces
Hi Eric, On Sun, Jun 14, 2015 at 10:07:30PM -0500, Eric W. Biederman wrote: > > While looking into what it would take to route packets out to network > devices in other network namespaces I started looking at the netfilter > hooks, and there is a lot of nasty code to figure out which network > namespace to filter the packets in. > > Just passing the network namespace into the netfilter hooks looks like a > significant simplication in the code, and worth it as the first thing > most netfilter hooks do is compute the network namespace. > > We probably even want per network namespace netfilter hooks as nftables > tries (and fails to use). nftables currently has a fairly serious bug > where the tables for one network namespace run for packets in all > network namespaces. I do not have a fix yet but I think this patchset > making it easy to get at the network namespace is a good starting > place for a fix. I have a patchset that is almost ready to convert netfilter to pernet hooks, it partially clashes with this. Will send it out today and will Cc you so you can review it. I think it should take me little time to rebase it on top of yours. It's rather large changeset, which quite a lot of boiler plate code though. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 00/15] Simplify netfilter and network namespaces
While looking into what it would take to route packets out to network devices in other network namespaces I started looking at the netfilter hooks, and there is a lot of nasty code to figure out which network namespace to filter the packets in. Just passing the network namespace into the netfilter hooks looks like a significant simplication in the code, and worth it as the first thing most netfilter hooks do is compute the network namespace. We probably even want per network namespace netfilter hooks as nftables tries (and fails to use). nftables currently has a fairly serious bug where the tables for one network namespace run for packets in all network namespaces. I do not have a fix yet but I think this patchset making it easy to get at the network namespace is a good starting place for a fix. This patshset roots out all of the very weird network namespace computation logic (except for the code in ipvs) and fixes it. I really don't like how the code has been essentially guessing which network namespace to use. Probably the worst guessing is in ipvs in the function skb_net. I have some preliminary changes to fix ipvs but they are not quite ready yet. Cleaning up ipvs enough that I can kill skb_net is on my short list. There are a few extra cleanups sprinkled in as I noticed a few other things as I was sorting out the network namespace computation logic. Eric W. Biederman (15): netfilter: Kill unused copies of RCV_SKB_FAIL netfilter: Pass struct net into the netfilter hooks netfilter: Use nf_hook_state.net ebtables: Simplify the arguments to ebt_do_table inet netfilter: Remove hook from ip6t_do_table, arp_do_table, ipt_do_table inet netfilter: Prefer state->hook to ops->hooknum nftables: kill nft_pktinfo.ops tc: Simplify em_ipset_match x_tables: Pass struct net in xt_action_param x_tables: Use par->net instead of computing from the passed net devices nftables: Pass struct net in nft_pktinfo nf_tables: Use pkt->net instead of computing net from the passed net_devices nf_conntrack: Add a struct net parameter to l4_pkt_to_tuple ipv4: Pass struct net into ip_defrag and ip_check_defrag ipv6: Pass struct net into nf_ct_frag6_gather drivers/net/macvlan.c | 2 +- include/linux/netfilter.h | 37 +++--- include/linux/netfilter/x_tables.h | 2 ++ include/linux/netfilter_arp/arp_tables.h | 1 - include/linux/netfilter_bridge/ebtables.h | 6 ++--- include/linux/netfilter_ingress.h | 2 +- include/linux/netfilter_ipv4/ip_tables.h | 1 - include/linux/netfilter_ipv6/ip6_tables.h | 1 - include/net/ip.h | 6 ++--- include/net/netfilter/ipv6/nf_defrag_ipv6.h| 2 +- include/net/netfilter/nf_conntrack.h | 3 ++- include/net/netfilter/nf_conntrack_core.h | 1 + include/net/netfilter/nf_conntrack_l4proto.h | 2 +- include/net/netfilter/nf_tables.h | 11 include/net/netfilter/nf_tables_ipv4.h | 3 +-- include/net/netfilter/nf_tables_ipv6.h | 3 +-- net/bridge/br_forward.c| 12 - net/bridge/br_input.c | 13 - net/bridge/br_multicast.c | 4 +-- net/bridge/br_netfilter.c | 37 ++ net/bridge/br_stp_bpdu.c | 4 +-- net/bridge/netfilter/ebt_log.c | 2 +- net/bridge/netfilter/ebt_nflog.c | 2 +- net/bridge/netfilter/ebtable_broute.c | 8 -- net/bridge/netfilter/ebtable_filter.c | 6 ++--- net/bridge/netfilter/ebtable_nat.c | 6 ++--- net/bridge/netfilter/ebtables.c| 14 +- net/bridge/netfilter/nf_tables_bridge.c| 16 +-- net/bridge/netfilter/nft_reject_bridge.c | 19 +++-- net/decnet/dn_neigh.c | 15 ++- net/decnet/dn_nsp_in.c | 4 +-- net/decnet/dn_route.c | 24 - net/ipv4/arp.c | 10 --- net/ipv4/ip_forward.c | 11 +--- net/ipv4/ip_fragment.c | 8 +++--- net/ipv4/ip_input.c| 30 - net/ipv4/ip_output.c | 28 +++ net/ipv4/ipmr.c| 6 ++--- net/ipv4/netfilter/arp_tables.c| 3 ++- net/ipv4/netfilter/arptable_filter.c | 5 +--- net/ipv4/netfilter/ip_tables.c | 11 net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +- net/ipv4/netfilter/ipt_SYNPROXY.c | 4 +-- net/ipv4/netfilter/ipt_rpfilter.c | 5 ++-- net/ipv4/netfilter/iptable_filter.c| 7 ++--- net/
