netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] openvswitch: call only into reachable nf-nat code
@ 2016-03-16 12:47 Arnd Bergmann
  2016-03-16 13:25 ` Pablo Neira Ayuso
       [not found] ` <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
  0 siblings, 2 replies; 6+ messages in thread
From: Arnd Bergmann @ 2016-03-16 12:47 UTC (permalink / raw)
  To: Pablo Neira Ayuso, Pravin Shelar, David S. Miller
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, Arnd Bergmann,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Joe Stringer, Paolo Abeni

The openvswitch code has gained support for calling into the
nf-nat-ipv4/ipv6 modules, however those can be loadable modules
in a configuration in which openvswitch is built-in, leading
to link errors:

net/built-in.o: In function `__ovs_ct_lookup':
:(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
:(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'

The dependency on (!NF_NAT || NF_NAT) was meant to prevent
this, but NF_NAT is set to 'y' if any of the symbols selecting
it are built-in, but the link error happens when any of them
are modular.

A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
to be useful in practice, but the driver currently only handles
IPv6 being optional.

This patch improves the Kconfig dependency so that openvswitch
cannot be built-in if either of the two other symbols are set
to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
with two "if (IS_ENABLED())" checks that should catch all corner
cases also make the code more readable.

The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
cause a link error, but for consistency I'm changing it the same
way.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
---
 net/openvswitch/Kconfig     |  3 ++-
 net/openvswitch/conntrack.c | 16 ++++++++--------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
index 234a73344c6e..961fb60115df 100644
--- a/net/openvswitch/Kconfig
+++ b/net/openvswitch/Kconfig
@@ -7,7 +7,8 @@ config OPENVSWITCH
 	depends on INET
 	depends on !NF_CONNTRACK || \
 		   (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
-				     (!NF_NAT || NF_NAT)))
+				     (!NF_NAT_IPV4 || NF_NAT_IPV4) && \
+				     (!NF_NAT_IPV6 || NF_NAT_IPV6)))
 	select LIBCRC32C
 	select MPLS
 	select NET_MPLS_GSO
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index dc5eb29fe7d6..ff04b5db04b3 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -535,14 +535,15 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
 	switch (ctinfo) {
 	case IP_CT_RELATED:
 	case IP_CT_RELATED_REPLY:
-		if (skb->protocol == htons(ETH_P_IP) &&
+		if (IS_ENABLED(CONFIG_NF_NAT_IPV4) &&
+		    skb->protocol == htons(ETH_P_IP) &&
 		    ip_hdr(skb)->protocol == IPPROTO_ICMP) {
 			if (!nf_nat_icmp_reply_translation(skb, ct, ctinfo,
 							   hooknum))
 				err = NF_DROP;
 			goto push;
-#if IS_ENABLED(CONFIG_NF_NAT_IPV6)
-		} else if (skb->protocol == htons(ETH_P_IPV6)) {
+		} else if (IS_ENABLED(CONFIG_NF_NAT_IPV6) &&
+			   skb->protocol == htons(ETH_P_IPV6)) {
 			__be16 frag_off;
 			u8 nexthdr = ipv6_hdr(skb)->nexthdr;
 			int hdrlen = ipv6_skip_exthdr(skb,
@@ -557,7 +558,6 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct nf_conn *ct,
 					err = NF_DROP;
 				goto push;
 			}
-#endif
 		}
 		/* Non-ICMP, fall thru to initialize if needed. */
 	case IP_CT_NEW:
@@ -1238,7 +1238,8 @@ static bool ovs_ct_nat_to_attr(const struct ovs_conntrack_info *info,
 	}
 
 	if (info->range.flags & NF_NAT_RANGE_MAP_IPS) {
-		if (info->family == NFPROTO_IPV4) {
+		if (IS_ENABLED(CONFIG_NF_NAT_IPV4) &&
+		    info->family == NFPROTO_IPV4) {
 			if (nla_put_in_addr(skb, OVS_NAT_ATTR_IP_MIN,
 					    info->range.min_addr.ip) ||
 			    (info->range.max_addr.ip
@@ -1246,8 +1247,8 @@ static bool ovs_ct_nat_to_attr(const struct ovs_conntrack_info *info,
 			     (nla_put_in_addr(skb, OVS_NAT_ATTR_IP_MAX,
 					      info->range.max_addr.ip))))
 				return false;
-#if IS_ENABLED(CONFIG_NF_NAT_IPV6)
-		} else if (info->family == NFPROTO_IPV6) {
+		} else if (IS_ENABLED(CONFIG_NF_NAT_IPV6) &&
+			   info->family == NFPROTO_IPV6) {
 			if (nla_put_in6_addr(skb, OVS_NAT_ATTR_IP_MIN,
 					     &info->range.min_addr.in6) ||
 			    (memcmp(&info->range.max_addr.in6,
@@ -1256,7 +1257,6 @@ static bool ovs_ct_nat_to_attr(const struct ovs_conntrack_info *info,
 			     (nla_put_in6_addr(skb, OVS_NAT_ATTR_IP_MAX,
 					       &info->range.max_addr.in6))))
 				return false;
-#endif
 		} else {
 			return false;
 		}
-- 
2.7.0

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
  2016-03-16 12:47 [PATCH] openvswitch: call only into reachable nf-nat code Arnd Bergmann
@ 2016-03-16 13:25 ` Pablo Neira Ayuso
  2016-03-16 13:56   ` Arnd Bergmann
       [not found] ` <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
  1 sibling, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2016-03-16 13:25 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Pravin Shelar, David S. Miller, Thomas Graf, Joe Stringer,
	Paolo Abeni, Jarno Rajahalme, netdev, dev, linux-kernel

On Wed, Mar 16, 2016 at 01:47:13PM +0100, Arnd Bergmann wrote:
> The openvswitch code has gained support for calling into the
> nf-nat-ipv4/ipv6 modules, however those can be loadable modules
> in a configuration in which openvswitch is built-in, leading
> to link errors:
> 
> net/built-in.o: In function `__ovs_ct_lookup':
> :(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
> :(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'
> 
> The dependency on (!NF_NAT || NF_NAT) was meant to prevent
> this, but NF_NAT is set to 'y' if any of the symbols selecting
> it are built-in, but the link error happens when any of them
> are modular.
> 
> A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
> CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
> to be useful in practice, but the driver currently only handles
> IPv6 being optional.
> 
> This patch improves the Kconfig dependency so that openvswitch
> cannot be built-in if either of the two other symbols are set
> to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
> with two "if (IS_ENABLED())" checks that should catch all corner
> cases also make the code more readable.
> 
> The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
> cause a link error, but for consistency I'm changing it the same
> way.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
> ---
>  net/openvswitch/Kconfig     |  3 ++-
>  net/openvswitch/conntrack.c | 16 ++++++++--------
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> index 234a73344c6e..961fb60115df 100644
> --- a/net/openvswitch/Kconfig
> +++ b/net/openvswitch/Kconfig
> @@ -7,7 +7,8 @@ config OPENVSWITCH
>  	depends on INET
>  	depends on !NF_CONNTRACK || \
>  		   (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
> -				     (!NF_NAT || NF_NAT)))
> +				     (!NF_NAT_IPV4 || NF_NAT_IPV4) && \
> +				     (!NF_NAT_IPV6 || NF_NAT_IPV6)))

Not related with this patch, just a side note/recommendation.

I understand this code just got into tree, and that this needs a bit
work/iterations but this thing above is ugly, I wonder if there is a
better way to avoid this.

Probably with some modularization of the openvswitch code this will
look better, I mean:

1) adding Kconfig switches to enable conntrack and NAT support to
   net/openvswitch/Kconfig.

2) Move the NAT code to the corresponding openvswitch/nat.c file.

Just my two cents.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
  2016-03-16 13:25 ` Pablo Neira Ayuso
@ 2016-03-16 13:56   ` Arnd Bergmann
  2016-03-17  2:54     ` Joe Stringer
  0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2016-03-16 13:56 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Joe Stringer, Paolo Abeni,
	David S. Miller

On Wednesday 16 March 2016 14:25:36 Pablo Neira Ayuso wrote:
> Not related with this patch, just a side note/recommendation.
> 
> I understand this code just got into tree, and that this needs a bit
> work/iterations but this thing above is ugly, I wonder if there is a
> better way to avoid this.
> 
> Probably with some modularization of the openvswitch code this will
> look better, I mean:
> 
> 1) adding Kconfig switches to enable conntrack and NAT support to
>    net/openvswitch/Kconfig.
> 
> 2) Move the NAT code to the corresponding openvswitch/nat.c file.
> 
> Just my two cents.

Yes, I think that would be good too. I also found that the driver
used to look like that but it was changed as part of f88f69dd17f1
("openvswitch: Remove conntrack Kconfig option.").

	Arnd

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
  2016-03-16 13:56   ` Arnd Bergmann
@ 2016-03-17  2:54     ` Joe Stringer
  0 siblings, 0 replies; 6+ messages in thread
From: Joe Stringer @ 2016-03-17  2:54 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: ovs dev, netdev, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paolo Abeni,
	David S. Miller, Pablo Neira Ayuso

On 17 March 2016 at 02:56, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 16 March 2016 14:25:36 Pablo Neira Ayuso wrote:
>> Not related with this patch, just a side note/recommendation.
>>
>> I understand this code just got into tree, and that this needs a bit
>> work/iterations but this thing above is ugly, I wonder if there is a
>> better way to avoid this.
>>
>> Probably with some modularization of the openvswitch code this will
>> look better, I mean:
>>
>> 1) adding Kconfig switches to enable conntrack and NAT support to
>>    net/openvswitch/Kconfig.
>>
>> 2) Move the NAT code to the corresponding openvswitch/nat.c file.
>>
>> Just my two cents.
>
> Yes, I think that would be good too. I also found that the driver
> used to look like that but it was changed as part of f88f69dd17f1
> ("openvswitch: Remove conntrack Kconfig option.").

I don't see how it helps to separate the conntrack, nat pieces into
different Kconfig switches unless you're splitting their code
completely out of the openvswitch module.

Prior to f88f69dd17f1, OPENVSWITCH Kconfig option had no dependency on
NF_CONNTRACK. OPENVSWITCH_CONNTRACK was a switch to build those pieces
into the OPENVSWITCH module (ie,
"openvswitch-$(CONFIG_OPENVSWITCH_CONNTRACK) += conntrack.o"). If you
configured NF_CONNTRACK=m, OPENVSWITCH=y, OPENVSWITCH_CONNTRACK=y then
it would break in the same kind of way as the bug that Arnd is
reporting. So, that patch was introduced to shift the dependency up to
the OPENVSWITCH kconfig option. At that point, there was no strong
benefit to keeping the conntrack separately configurable, so that was
removed. Further splitting the code out in some way (eg new modules)
seemed way overkill to tidy up some ugly-looking dependency logic.

Maybe someone with better Kconfig-fu than me can point out a better way.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
       [not found] ` <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
@ 2016-03-17  3:09   ` Joe Stringer
  2016-03-18 12:57   ` Arnd Bergmann
  1 sibling, 0 replies; 6+ messages in thread
From: Joe Stringer @ 2016-03-17  3:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: ovs dev, netdev, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Joe Stringer, Paolo Abeni, David S. Miller, Pablo Neira Ayuso

On 17 March 2016 at 01:47, Arnd Bergmann <arnd@arndb.de> wrote:
> The openvswitch code has gained support for calling into the
> nf-nat-ipv4/ipv6 modules, however those can be loadable modules
> in a configuration in which openvswitch is built-in, leading
> to link errors:
>
> net/built-in.o: In function `__ovs_ct_lookup':
> :(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
> :(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'
>
> The dependency on (!NF_NAT || NF_NAT) was meant to prevent
> this, but NF_NAT is set to 'y' if any of the symbols selecting
> it are built-in, but the link error happens when any of them
> are modular.
>
> A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
> CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
> to be useful in practice, but the driver currently only handles
> IPv6 being optional.
>
> This patch improves the Kconfig dependency so that openvswitch
> cannot be built-in if either of the two other symbols are set
> to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
> with two "if (IS_ENABLED())" checks that should catch all corner
> cases also make the code more readable.
>
> The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
> cause a link error, but for consistency I'm changing it the same
> way.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")

Thanks for the fix, LGTM.

Acked-by: Joe Stringer <joe@ovn.org>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
       [not found] ` <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
  2016-03-17  3:09   ` Joe Stringer
@ 2016-03-18 12:57   ` Arnd Bergmann
  1 sibling, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2016-03-18 12:57 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Joe Stringer, Paolo Abeni,
	David S. Miller

On Wednesday 16 March 2016 13:47:13 Arnd Bergmann wrote:
> The openvswitch code has gained support for calling into the
> nf-nat-ipv4/ipv6 modules, however those can be loadable modules
> in a configuration in which openvswitch is built-in, leading
> to link errors:
> 
> net/built-in.o: In function `__ovs_ct_lookup':
> :(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
> :(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'
> 
> The dependency on (!NF_NAT || NF_NAT) was meant to prevent
> this, but NF_NAT is set to 'y' if any of the symbols selecting
> it are built-in, but the link error happens when any of them
> are modular.
> 
> A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
> CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
> to be useful in practice, but the driver currently only handles
> IPv6 being optional.
> 
> This patch improves the Kconfig dependency so that openvswitch
> cannot be built-in if either of the two other symbols are set
> to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
> with two "if (IS_ENABLED())" checks that should catch all corner
> cases also make the code more readable.
> 
> The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
> cause a link error, but for consistency I'm changing it the same
> way.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
> ---
>  net/openvswitch/Kconfig     |  3 ++-
>  net/openvswitch/conntrack.c | 16 ++++++++--------
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> index 234a73344c6e..961fb60115df 100644
> --- a/net/openvswitch/Kconfig
> +++ b/net/openvswitch/Kconfig
> @@ -7,7 +7,8 @@ config OPENVSWITCH
>  	depends on INET
>  	depends on !NF_CONNTRACK || \
>  		   (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
> -				     (!NF_NAT || NF_NAT)))
> +				     (!NF_NAT_IPV4 || NF_NAT_IPV4) && \
> +				     (!NF_NAT_IPV6 || NF_NAT_IPV6)))
>  	select LIBCRC32C
>  	select MPLS
>  	select NET_MPLS_GSO

I've now seen a new regression:

net/built-in.o: In function `__ovs_ct_lookup':
switchdev.c:(.text+0x136e8c): undefined reference to `nf_ct_nat_ext_add'
switchdev.c:(.text+0x136f38): undefined reference to `nf_nat_packet'
switchdev.c:(.text+0x136f80): undefined reference to `nf_nat_setup_info'
switchdev.c:(.text+0x136f98): undefined reference to `nf_nat_alloc_null_binding'

Apparently, the (!NF_NAT || NF_NAT) statement is also needed in addition to
the other two. I'm resending the fixed patch, as it doesn't seem to have
been merged yet.

If it's in some other tree already and you'd rather have a patch on top,
I can send that too.

	Arnd
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-03-18 12:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-16 12:47 [PATCH] openvswitch: call only into reachable nf-nat code Arnd Bergmann
2016-03-16 13:25 ` Pablo Neira Ayuso
2016-03-16 13:56   ` Arnd Bergmann
2016-03-17  2:54     ` Joe Stringer
     [not found] ` <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
2016-03-17  3:09   ` Joe Stringer
2016-03-18 12:57   ` Arnd Bergmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).