Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.

Eric Dumazet
2014-12-09T14:26:53Z

On Tue, 2014-12-09 at 09:54 +0100, Thomas Jarosch wrote:
> On Monday, 8. December 2014 23:20:42 Wolfgang Walter wrote:
> > 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
> > :-).
>
> If it helps, I'm running the reverted patch on five production boxes hitherto
> without a hiccup. As far as I understood the original commit message,
> some packet counters might me wrong without it.
>
> @Eric: What could possibly go wrong(tm)? :)

Crashes in TCP stack, because of packet count mismatches.

The sk_can_gso() status is already tested in tcp_sendmsg() as a hint,
since path behavior can dynamically be changed on existing flow :

<start a TCP flow>
ethtool -K eth0 tso off gso off

In this case, core networking stack detects this and segments the
packets _after_ TCP or IP stack, before they reach eth0.

TCP stack does not have to know that something is changed right before
giving a GSO packet to core networking stack, this would be racy by
nature, as TCP does not know or control full path. Hopefully we do not
take RTNL for every packet we send in TCP !

It seems XFRM triggers in a slow path something which is not correctly
handled.

It is not correct to add a racy kludge in TCP fast path for this very
unlikely case.

I would disable TSO/GSO on xfrm, and problem should disappear.