On Fri, 2015-06-05 at 16:02 -0700, Martin KaFai Lau wrote:
> On Fri, Jun 05, 2015 at 02:23:55PM -0700, Eric Dumazet wrote:
> > On Fri, 2015-06-05 at 11:02 -0700, Martin KaFai Lau wrote:
> >
> > > tcp_trim_head() does not take the mss_now.
> > > Is it fine to have mss_now <= tcp_skb_mss(skb)? or we
On Fri, Jun 05, 2015 at 02:23:55PM -0700, Eric Dumazet wrote:
> On Fri, 2015-06-05 at 11:02 -0700, Martin KaFai Lau wrote:
>
> > tcp_trim_head() does not take the mss_now.
> > Is it fine to have mss_now <= tcp_skb_mss(skb)? or we can depend on
> > the tcp_init_tso_segs() in the tcp_write_xmit() to
On Fri, 2015-06-05 at 11:02 -0700, Martin KaFai Lau wrote:
> tcp_trim_head() does not take the mss_now.
> Is it fine to have mss_now <= tcp_skb_mss(skb)? or we can depend on
> the tcp_init_tso_segs() in the tcp_write_xmit() to take care of it?
It should be fine : packets not yet sent have tcp_skb
On Fri, Jun 05, 2015 at 09:53:51AM -0700, Eric Dumazet wrote:
> Sounds good, although I would simply get rid of all this complexity in
> this very unlikely path.
>
> Would you instead try the following ?
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index
> eeb59befaf06867b00e
On Fri, Jun 5, 2015 at 9:16 AM, Martin KaFai Lau wrote:
> The problem is caught by this WARN_ON(len > skb->len) in tcp_fragment():
>
> [] warn_slowpath_null+0x1a/0x20
> [] tcp_fragment+0x2a0/0x2b0
> [] tcp_mark_head_lost+0x196/0x230
> [] tcp_update_scoreboard+0x4d/0x80
> [] tcp_fastretrans_alert+0
The problem is caught by this WARN_ON(len > skb->len) in tcp_fragment():
[] warn_slowpath_null+0x1a/0x20
[] tcp_fragment+0x2a0/0x2b0
[] tcp_mark_head_lost+0x196/0x230
[] tcp_update_scoreboard+0x4d/0x80
[] tcp_fastretrans_alert+0x6ac/0xa90
[] tcp_ack+0x9d4/0x10e0
[] tcp_rcv_established+0x309/0x7e0
