Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Thomas Deutschmann]

Hi,

please add

> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Thu, 25 Jan 2018 19:03:03 +0100
> Subject: net: don't call update_pmtu unconditionally
> 
> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
> 
> Let's add a helper to check if update_pmtu is available before calling it.
> 
> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> CC: Roman Kapl <code@rkapl.cz>
> CC: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

to 4.14.x.

This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
skb dst pmtu on tx path"), which was backported to 4.14.24.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Thomas Deutschmann]

On 2018-04-22 23:50, Thomas Deutschmann wrote:
> Hi,
> 
> please add
> 
>> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Date: Thu, 25 Jan 2018 19:03:03 +0100
>> Subject: net: don't call update_pmtu unconditionally
>>
>> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
>> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
>>
>> Let's add a helper to check if update_pmtu is available before calling it.
>>
>> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
>> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
>> CC: Roman Kapl <code@rkapl.cz>
>> CC: Xin Long <lucien.xin@gmail.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> to 4.14.x.
> 
> This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> skb dst pmtu on tx path"), which was backported to 4.14.24.

*ping* - Not yet applied and not yet queued. Is there a problem with the
patch which prevents a cherry-pick for 4.14.x?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > Hi,
> > 
> > please add
> > 
> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> >> Subject: net: don't call update_pmtu unconditionally
> >>
> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> >> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
> >>
> >> Let's add a helper to check if update_pmtu is available before calling it.
> >>
> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> >> CC: Roman Kapl <code@rkapl.cz>
> >> CC: Xin Long <lucien.xin@gmail.com>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> > 
> > to 4.14.x.
> > 
> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > skb dst pmtu on tx path"), which was backported to 4.14.24.
> 
> *ping* - Not yet applied and not yet queued. Is there a problem with the
> patch which prevents a cherry-pick for 4.14.x?

This looks like an "obvious" fix for me to pick up.

Dave, any objections for me just grabbing it as-is?

thanks,

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[David Miller]

From: Greg KH <gregkh@linuxfoundation.org>
Date: Fri, 27 Apr 2018 15:51:25 +0200

> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
>> On 2018-04-22 23:50, Thomas Deutschmann wrote:
>> > Hi,
>> > 
>> > please add
>> > 
>> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
>> >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
>> >> Subject: net: don't call update_pmtu unconditionally
>> >>
>> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
>> >> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
>> >>
>> >> Let's add a helper to check if update_pmtu is available before calling it.
>> >>
>> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
>> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
>> >> CC: Roman Kapl <code@rkapl.cz>
>> >> CC: Xin Long <lucien.xin@gmail.com>
>> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Signed-off-by: David S. Miller <davem@davemloft.net>
>> > 
>> > to 4.14.x.
>> > 
>> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
>> > skb dst pmtu on tx path"), which was backported to 4.14.24.
>> 
>> *ping* - Not yet applied and not yet queued. Is there a problem with the
>> patch which prevents a cherry-pick for 4.14.x?
> 
> This looks like an "obvious" fix for me to pick up.
> 
> Dave, any objections for me just grabbing it as-is?

No objections, thanks everyone.

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 03:51:25PM +0200, Greg KH wrote:
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> > On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > > Hi,
> > > 
> > > please add
> > > 
> > >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> > >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> > >> Subject: net: don't call update_pmtu unconditionally
> > >>
> > >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> > >> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
> > >>
> > >> Let's add a helper to check if update_pmtu is available before calling it.
> > >>
> > >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> > >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> > >> CC: Roman Kapl <code@rkapl.cz>
> > >> CC: Xin Long <lucien.xin@gmail.com>
> > >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Signed-off-by: David S. Miller <davem@davemloft.net>
> > > 
> > > to 4.14.x.
> > > 
> > > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > > skb dst pmtu on tx path"), which was backported to 4.14.24.
> > 
> > *ping* - Not yet applied and not yet queued. Is there a problem with the
> > patch which prevents a cherry-pick for 4.14.x?
> 
> This looks like an "obvious" fix for me to pick up.

Well, it would be "obvious" if it actually applied to the 4.14.y tree :(

Thomas, did you try this patch out?  I can't apply it as-is, it will
need a backport.  Please work on that, and test it out, as I don't get
the impression that you did that here.

Then post the working backport and I'll be glad to consider it for
future 4.14.y releases.

thanks,

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Eddie Chapman]

On 27/04/18 15:45, Greg KH wrote:
> On Fri, Apr 27, 2018 at 03:51:25PM +0200, Greg KH wrote:
>> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
>>> On 2018-04-22 23:50, Thomas Deutschmann wrote:
>>>> Hi,
>>>>
>>>> please add
>>>>
>>>>>  From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
>>>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>> Date: Thu, 25 Jan 2018 19:03:03 +0100
>>>>> Subject: net: don't call update_pmtu unconditionally
>>>>>
>>>>> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
>>>>> "BUG: unable to handle kernel NULL pointer dereference at           (null)"
>>>>>
>>>>> Let's add a helper to check if update_pmtu is available before calling it.
>>>>>
>>>>> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
>>>>> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
>>>>> CC: Roman Kapl <code@rkapl.cz>
>>>>> CC: Xin Long <lucien.xin@gmail.com>
>>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>
>>>> to 4.14.x.
>>>>
>>>> This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
>>>> skb dst pmtu on tx path"), which was backported to 4.14.24.
>>>
>>> *ping* - Not yet applied and not yet queued. Is there a problem with the
>>> patch which prevents a cherry-pick for 4.14.x?
>>
>> This looks like an "obvious" fix for me to pick up.
> 
> Well, it would be "obvious" if it actually applied to the 4.14.y tree :(
> 
> Thomas, did you try this patch out?  I can't apply it as-is, it will
> need a backport.  Please work on that, and test it out, as I don't get
> the impression that you did that here.
> 
> Then post the working backport and I'll be glad to consider it for
> future 4.14.y releases.
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

I just applied coreos' 4.14 backport of this to your 4.14.38-rc1, which 
booted and is running with no problem:

https://github.com/coreos/linux/commit/f5f2102a531988e24f19a13fdc5b8206007aaad5

AFAIK their backport is already in a coreos release so has received testing.

Comparing their backport to the original, I can see they just needed to 
make the same trivial change to each hunk to make it apply on 4.14.

The backport is linked from this bug report, which is I believe what led 
to the backport being requested here in the first place:
https://github.com/coreos/bugs/issues/2382

Up to you of course if you trust it, just posting in case it helps.

Eddie

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Thomas Deutschmann]

Hi Greg,

first, we need to cherry-pick another patch first:
 
> From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
> From: Xin Long <lucien.xin@gmail.com>
> Date: Mon, 25 Dec 2017 14:43:58 +0800
> Subject: [PATCH] geneve: update skb dst pmtu on tx path
> 
> Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
> a performance issue caused by the change of lower dev's mtu for vxlan.
> 
> The same thing needs to be done for geneve as well.
> 
> Note that geneve cannot adjust it's mtu according to lower dev's mtu
> when creating it. The performance is very low later when netperfing
> over it without fixing the mtu manually. This patch could also avoid
> this issue.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Then you can apply the following backport. A backport is required
because v4.15 has commit 77552cfa39c48e695c39d0553afc8c6018e411ce
which rewrote

> skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2, rel_info);

into

> 		skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2,
> 						rel_info);

in net/ipv6/ip6_tunnel.c which is missing:

>From b2fb9a8178660f92c6ab29d3171bc44e2cb1b618 Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 25 Jan 2018 19:03:03 +0100
Subject: net: don't call update_pmtu unconditionally

commit f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 upstream.

Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
"BUG: unable to handle kernel NULL pointer dereference at           (null)"

Let's add a helper to check if update_pmtu is available before calling it.

Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
CC: Roman Kapl <code@rkapl.cz>
CC: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c | 3 +--
 drivers/net/geneve.c                    | 4 ++--
 drivers/net/vxlan.c                     | 6 ++----
 include/net/dst.h                       | 8 ++++++++
 net/ipv4/ip_tunnel.c                    | 3 +--
 net/ipv4/ip_vti.c                       | 2 +-
 net/ipv6/ip6_tunnel.c                   | 5 ++---
 net/ipv6/ip6_vti.c                      | 2 +-
 net/ipv6/sit.c                          | 4 ++--
 9 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 7774654c2ccb..7a5ed5a5391e 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1447,8 +1447,7 @@ void ipoib_cm_skb_too_long(struct net_device *dev, struct sk_buff *skb,
 	struct ipoib_dev_priv *priv = ipoib_priv(dev);
 	int e = skb_queue_empty(&priv->cm.skb_queue);
 
-	if (skb_dst(skb))
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+	skb_dst_update_pmtu(skb, mtu);
 
 	skb_queue_tail(&priv->cm.skb_queue, skb);
 	if (e)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 1b0fcf0b2afa..fbc825ac97ab 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -829,7 +829,7 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
 		int mtu = dst_mtu(&rt->dst) - sizeof(struct iphdr) -
 			  GENEVE_BASE_HLEN - info->options_len - 14;
 
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+		skb_dst_update_pmtu(skb, mtu);
 	}
 
 	sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
@@ -875,7 +875,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
 		int mtu = dst_mtu(dst) - sizeof(struct ipv6hdr) -
 			  GENEVE_BASE_HLEN - info->options_len - 14;
 
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+		skb_dst_update_pmtu(skb, mtu);
 	}
 
 	sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bb44f0c6891f..3d9c5b35a4a7 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2158,8 +2158,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
 		if (skb_dst(skb)) {
 			int mtu = dst_mtu(ndst) - VXLAN_HEADROOM;
 
-			skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
-						       skb, mtu);
+			skb_dst_update_pmtu(skb, mtu);
 		}
 
 		tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
@@ -2200,8 +2199,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
 		if (skb_dst(skb)) {
 			int mtu = dst_mtu(ndst) - VXLAN6_HEADROOM;
 
-			skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
-						       skb, mtu);
+			skb_dst_update_pmtu(skb, mtu);
 		}
 
 		tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
diff --git a/include/net/dst.h b/include/net/dst.h
index 694c2e6ae618..ebfb4328fdb1 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -520,4 +520,12 @@ static inline struct xfrm_state *dst_xfrm(const struct dst_entry *dst)
 }
 #endif
 
+static inline void skb_dst_update_pmtu(struct sk_buff *skb, u32 mtu)
+{
+	struct dst_entry *dst = skb_dst(skb);
+
+	if (dst && dst->ops->update_pmtu)
+		dst->ops->update_pmtu(dst, NULL, skb, mtu);
+}
+
 #endif /* _NET_DST_H */
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 13f7bbc0168d..a2fcc20774a6 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -521,8 +521,7 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
 	else
 		mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
 
-	if (skb_dst(skb))
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+	skb_dst_update_pmtu(skb, mtu);
 
 	if (skb->protocol == htons(ETH_P_IP)) {
 		if (!skb_is_gso(skb) &&
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 89453cf62158..c9cd891f69c2 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -209,7 +209,7 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct net_device *dev,
 
 	mtu = dst_mtu(dst);
 	if (skb->len > mtu) {
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+		skb_dst_update_pmtu(skb, mtu);
 		if (skb->protocol == htons(ETH_P_IP)) {
 			icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
 				  htonl(mtu));
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 7e11f6a811f5..d61a82fd4b60 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -652,7 +652,7 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
 		if (rel_info > dst_mtu(skb_dst(skb2)))
 			goto out;
 
-		skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2, rel_info);
+		skb_dst_update_pmtu(skb2, rel_info);
 	}
 	if (rel_type == ICMP_REDIRECT)
 		skb_dst(skb2)->ops->redirect(skb_dst(skb2), NULL, skb2);
@@ -1141,8 +1141,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
 		mtu = 576;
 	}
 
-	if (skb_dst(skb) && !t->parms.collect_md)
-		skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+	skb_dst_update_pmtu(skb, mtu);
 	if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
 		*pmtu = mtu;
 		err = -EMSGSIZE;
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 7c0f647b5195..2493a40bc4b1 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -486,7 +486,7 @@ vti6_xmit(struct sk_buff *skb, struct net_device *dev, struct flowi *fl)
 
 	mtu = dst_mtu(dst);
 	if (!skb->ignore_df && skb->len > mtu) {
-		skb_dst(skb)->ops->update_pmtu(dst, NULL, skb, mtu);
+		skb_dst_update_pmtu(skb, mtu);
 
 		if (skb->protocol == htons(ETH_P_IPV6)) {
 			if (mtu < IPV6_MIN_MTU)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index f03c1a562135..b35d8905794c 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -925,8 +925,8 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
 			df = 0;
 		}
 
-		if (tunnel->parms.iph.daddr && skb_dst(skb))
-			skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
+		if (tunnel->parms.iph.daddr)
+			skb_dst_update_pmtu(skb, mtu);
 
 		if (skb->len > mtu && !skb_is_gso(skb)) {
 			icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
-- 
2.17.0

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Eddie Chapman]

On 27/04/18 19:07, Thomas Deutschmann wrote:
> Hi Greg,
> 
> first, we need to cherry-pick another patch first:
>   
>>  From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
>> From: Xin Long <lucien.xin@gmail.com>
>> Date: Mon, 25 Dec 2017 14:43:58 +0800
>> Subject: [PATCH] geneve: update skb dst pmtu on tx path
>>
>> Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
>> a performance issue caused by the change of lower dev's mtu for vxlan.
>>
>> The same thing needs to be done for geneve as well.
>>
>> Note that geneve cannot adjust it's mtu according to lower dev's mtu
>> when creating it. The performance is very low later when netperfing
>> over it without fixing the mtu manually. This patch could also avoid
>> this issue.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>

Oops, I completely missed that the coreos patch doesn't have the geneve 
hunk that is in the original 4.15 patch. I don't load the geneve module 
on my box hence why no problems surfaced on my machine.

Thanks Thomas for the correct instructions. Ignore my message Greg, I'll 
drop back into the shadows where I belong, sorry for the noise!

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 07:43:52PM +0100, Eddie Chapman wrote:
> On 27/04/18 19:07, Thomas Deutschmann wrote:
> > Hi Greg,
> > 
> > first, we need to cherry-pick another patch first:
> > >  From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
> > > From: Xin Long <lucien.xin@gmail.com>
> > > Date: Mon, 25 Dec 2017 14:43:58 +0800
> > > Subject: [PATCH] geneve: update skb dst pmtu on tx path
> > > 
> > > Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
> > > a performance issue caused by the change of lower dev's mtu for vxlan.
> > > 
> > > The same thing needs to be done for geneve as well.
> > > 
> > > Note that geneve cannot adjust it's mtu according to lower dev's mtu
> > > when creating it. The performance is very low later when netperfing
> > > over it without fixing the mtu manually. This patch could also avoid
> > > this issue.
> > > 
> > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> Oops, I completely missed that the coreos patch doesn't have the geneve hunk
> that is in the original 4.15 patch. I don't load the geneve module on my box
> hence why no problems surfaced on my machine.
> 
> Thanks Thomas for the correct instructions. Ignore my message Greg, I'll
> drop back into the shadows where I belong, sorry for the noise!

Talking about patches and pointing me at them is not noise at all, don't
be sorry! :)

I'll work on this after these next kernels are released, thanks all for
the details on what needs to be done.

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 07:43:52PM +0100, Eddie Chapman wrote:
> On 27/04/18 19:07, Thomas Deutschmann wrote:
> > Hi Greg,
> > 
> > first, we need to cherry-pick another patch first:
> > >  From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
> > > From: Xin Long <lucien.xin@gmail.com>
> > > Date: Mon, 25 Dec 2017 14:43:58 +0800
> > > Subject: [PATCH] geneve: update skb dst pmtu on tx path
> > > 
> > > Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
> > > a performance issue caused by the change of lower dev's mtu for vxlan.
> > > 
> > > The same thing needs to be done for geneve as well.
> > > 
> > > Note that geneve cannot adjust it's mtu according to lower dev's mtu
> > > when creating it. The performance is very low later when netperfing
> > > over it without fixing the mtu manually. This patch could also avoid
> > > this issue.
> > > 
> > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> Oops, I completely missed that the coreos patch doesn't have the geneve hunk
> that is in the original 4.15 patch. I don't load the geneve module on my box
> hence why no problems surfaced on my machine.

The geneve hunk doesn't apply at all to the 4.14.y tree, so I think
someone has a messed up tree somewhere...

I'll go look into this now.

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Thomas Deutschmann]

Hi,

On 2018-04-30 20:22, Greg KH wrote:
> The geneve hunk doesn't apply at all to the 4.14.y tree, so I think
> someone has a messed up tree somewhere...
> 
> I'll go look into this now.

Mh?

> $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> $ cd linux-stable
> $ git checkout v4.14.38
> $ git cherry-pick 52a589d51f1008f62569bf89e95b26221ee76690

Works for me... then I cherry-pick
f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 on top, adjust
"net/ipv6/ip6_tunnel.c" like shown in my previous mail and everything is
fine for me...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Tue, May 01, 2018 at 12:15:37AM +0200, Thomas Deutschmann wrote:
> Hi,
> 
> On 2018-04-30 20:22, Greg KH wrote:
> > The geneve hunk doesn't apply at all to the 4.14.y tree, so I think
> > someone has a messed up tree somewhere...
> > 
> > I'll go look into this now.
> 
> Mh?
> 
> > $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > $ cd linux-stable
> > $ git checkout v4.14.38
> > $ git cherry-pick 52a589d51f1008f62569bf89e95b26221ee76690
> 
> Works for me... then I cherry-pick
> f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 on top, adjust
> "net/ipv6/ip6_tunnel.c" like shown in my previous mail and everything is
> fine for me...

Ah crap, I missed the dependancy here as well, it was a long day
yesterday...

I'll drop this and try it again for the next release.

greg k-h