[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5642727.qTG53DqrAk@h2o.as.studentenwerk.mhn.de>
Date: Mon, 08 Dec 2014 23:20:42 +0100
From: Wolfgang Walter <linux@...m.de>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org,
Thomas Jarosch <thomas.jarosch@...ra2net.com>,
Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.12+
Am Freitag, 5. Dezember 2014, 05:26:25 schrieb Eric Dumazet:
> On Fri, 2014-12-05 at 13:09 +0100, Wolfgang Walter wrote:
> > Hello,
> >
> > as reverting this patch fixes this rather annoying problem: is it
> > dangerous to revert it as a workaround until the root cause is found?
>
> Unfortunately no, this patch fixes a serious issue.
>
> We need to find the root cause of your problem instead of trying to work
> around it.
>
I only wanted to use it as local workaround here.
I looked a bit at at code. I'm not familiar with the network code, though :-).
When exactly should the gso handling with esp tunnel mode happen?
esp_output_done() calls xfrm_output_resume() and no gso handling is done.
Would be to late anyway.
esp_output() does not handle gso.
xfrm4_mode_tunnel_output() does not do any gso handling as far as I can see.
xfrm_output() (from net/xfrm/xfrm_output) does but is it called with esp
tunnel mode?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists