On Fri, 2017-11-03 at 19:22 +0100, Oleksandr Natalenko wrote:
> Hi.
>
> Thanks for the fix.
>
> However, tcp_fastretrans_alert() warning case still remains open even with
> this patch. Do I understand correctly that these are 2 different issues?
>
> Currently, I use latest 4.13 stable kernel +
Hi.
Thanks for the fix.
However, tcp_fastretrans_alert() warning case still remains open even with
this patch. Do I understand correctly that these are 2 different issues?
Currently, I use latest 4.13 stable kernel + this patch and still get:
WARNING: CPU: 1 PID: 736 at net/ipv4/tcp_input.c:28
From: Eric Dumazet
Date: Mon, 30 Oct 2017 23:08:20 -0700
> From: Eric Dumazet
>
> Based on SNMP values provided by Roman, Yuchung made the observation
> that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
>
> Looking at tcp_mtu_probe(), I found that when a new skb was place
On Mon, Oct 30, 2017 at 11:17 PM, Alexei Starovoitov
wrote:
>
> On Mon, Oct 30, 2017 at 11:08:20PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > Based on SNMP values provided by Roman, Yuchung made the observation
> > that some crashes in tcp_sacktag_walk() might be caused by MTU prob
On Tue, Oct 31, 2017 at 2:08 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Based on SNMP values provided by Roman, Yuchung made the observation
> that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
>
> Looking at tcp_mtu_probe(), I found that when a new skb was placed
> in
On Mon, Oct 30, 2017 at 11:21:42PM -0700, Eric Dumazet wrote:
> On Mon, 2017-10-30 at 23:17 -0700, Alexei Starovoitov wrote:
> > On Mon, Oct 30, 2017 at 11:08:20PM -0700, Eric Dumazet wrote:
> > > From: Eric Dumazet
> > >
> > > Based on SNMP values provided by Roman, Yuchung made the observation
On Mon, 2017-10-30 at 23:17 -0700, Alexei Starovoitov wrote:
> On Mon, Oct 30, 2017 at 11:08:20PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > Based on SNMP values provided by Roman, Yuchung made the observation
> > that some crashes in tcp_sacktag_walk() might be caused by MTU probi
On Mon, Oct 30, 2017 at 11:08:20PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Based on SNMP values provided by Roman, Yuchung made the observation
> that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
>
> Looking at tcp_mtu_probe(), I found that when a new skb was pl
From: Eric Dumazet
Based on SNMP values provided by Roman, Yuchung made the observation
that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
Looking at tcp_mtu_probe(), I found that when a new skb was placed
in front of the write queue, we were not updating tcp highest sack.