From: Mark McKinstry <Mark.McKinstry@alliedtelesis.co.nz>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"alexander.h.duyck@redhat.com" <alexander.h.duyck@redhat.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH] vti6: Add pmtu handling to vti6_xmit.
Date: Wed, 30 Mar 2016 21:04:03 +0000 [thread overview]
Message-ID: <56FC3F3D.2000408@alliedtelesis.co.nz> (raw)
In-Reply-To: <20160322105318.GS3347@gauss.secunet.com>
I've tested this patch in our scenario and I can confirm that it still
fixes all of our issues.
On 22/03/16 23:53, Steffen Klassert wrote:
> On Tue, Mar 15, 2016 at 01:28:01PM +0100, Steffen Klassert wrote:
>> On Mon, Mar 14, 2016 at 09:52:05PM +0000, Mark McKinstry wrote:
>>> Your patch adds a dst_release() call to my suggested fix, but this is
>>> problematic because the kfree_skb() call at tx_error already takes care
>>> of releasing dst - via kfree_skb() > __kfree_skb() > skb_release_all() >
>>> skb_release_head_state() > skb_dst_drop()
>>> > refdst_drop() > dst_release(). In our scenario your patch results in
>>> a negative refcount kernel warning being generated in dst_release() for
>>> every packet that is too big to go over the vti.
>> Hm. I've just noticed that my pmtu test does not trigger this
>> codepath, so I did not see the warning.
>>
>> Seems like we do the pmtu handling too late, it should happen before
>> we do skb_dst_set(). Also skb_scrub_packet() resets skb->ignore_df,
>> so checking ignore_df after skb_scrub_packet() does not make much sense.
>>
>> I'll send an updated version after some more testing.
>>
> I've added a testcase that triggers this codepath to my testing
> environment. The patch below works for me, could you please test
> if it fixes your problems?
>
> Subject: [PATCH] vti: Add pmtu handling to vti_xmit.
>
> We currently rely on the PMTU discovery of xfrm.
> However if a packet is locally sent, the PMTU mechanism
> of xfrm tries to do local socket notification what
> might not work for applications like ping that don't
> check for this. So add pmtu handling to vti_xmit to
> report MTU changes immediately.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv4/ip_vti.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
> index 5cf10b7..a917903 100644
> --- a/net/ipv4/ip_vti.c
> +++ b/net/ipv4/ip_vti.c
> @@ -156,6 +156,7 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct net_device *dev,
> struct dst_entry *dst = skb_dst(skb);
> struct net_device *tdev; /* Device to other host */
> int err;
> + int mtu;
>
> if (!dst) {
> dev->stats.tx_carrier_errors++;
> @@ -192,6 +193,23 @@ static netdev_tx_t vti_xmit(struct sk_buff *skb, struct net_device *dev,
> tunnel->err_count = 0;
> }
>
> + mtu = dst_mtu(dst);
> + if (skb->len > mtu) {
> + skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
> + if (skb->protocol == htons(ETH_P_IP)) {
> + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
> + htonl(mtu));
> + } else {
> + if (mtu < IPV6_MIN_MTU)
> + mtu = IPV6_MIN_MTU;
> +
> + icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
> + }
> +
> + dst_release(dst);
> + goto tx_error;
> + }
> +
> skb_scrub_packet(skb, !net_eq(tunnel->net, dev_net(dev)));
> skb_dst_set(skb, dst);
> skb->dev = skb_dst(skb)->dev;
next prev parent reply other threads:[~2016-03-30 21:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 17:40 [PATCH] xfrm6: Do not use xfrm_local_error for path MTU issues in tunnels Alexander Duyck
2015-05-28 4:49 ` Herbert Xu
2015-05-28 4:56 ` Steffen Klassert
2015-05-28 5:36 ` Steffen Klassert
2015-05-28 7:18 ` Alexander Duyck
2015-05-28 8:40 ` Steffen Klassert
2015-05-28 19:15 ` Alexander Duyck
2015-05-29 16:53 ` Alexander Duyck
2015-05-29 18:28 ` [PATCH] vti6: Add pmtu handling to vti6_xmit Alexander Duyck
2015-06-01 23:04 ` David Miller
2016-02-10 1:50 ` Mark McKinstry
2016-02-17 7:08 ` Steffen Klassert
2016-02-18 1:40 ` Mark McKinstry
2016-02-18 12:19 ` Steffen Klassert
2016-02-24 21:37 ` Mark McKinstry
2016-02-25 11:21 ` Steffen Klassert
2016-03-04 7:05 ` Steffen Klassert
2016-03-14 21:52 ` Mark McKinstry
2016-03-15 12:28 ` Steffen Klassert
2016-03-22 10:53 ` Steffen Klassert
2016-03-30 21:04 ` Mark McKinstry [this message]
2016-04-01 8:08 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FC3F3D.2000408@alliedtelesis.co.nz \
--to=mark.mckinstry@alliedtelesis.co.nz \
--cc=alexander.h.duyck@redhat.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.