Re: Recurring trace from tcp_fragment()

[Grant Zhang <gzhang@fastly.com>]

Hi Martin,

Thank you! My net.ipv4.tcp_mtu_probing is 1. After turning it off, the 
WARN_ON stack is gone.

Could you elaborate a bit on why this setting relates to the WARN_ON 
trace? And what are the pros/cons for disabling mtu_probing?

Thanks,

Grant

On 6/4/15 12:38 PM, Martin KaFai Lau wrote:
> Hi Grant,
>
> On Thu, Jun 04, 2015 at 09:35:04AM -0700, Grant Zhang wrote:
>> Hi Neal,
>>
>> Unfortunately with the patch we still see the same stack trace.
>> Attached is the TcpExtTCPSACKReneging with the patch, captured with
>> 60 seconds interval. Its value is incremented at an similar speed as
>> before, about 30/minute.
>>
>> If you want to collect any other data, please feel free to let me know.
>>
>
> We are also seeing similar WARN_ON stack in our kernel 4.0 testing.
>
> What is your net.ipv4.tcp_mtu_probing setting?  I am currently testing some
> code changes and waiting for some more data.  If it is 1 or 2,
> can you help to check whether turning it off (by setting it to 0) will stop the
> WARN_ON or not in your environment?  Note that after setting it to 0, you
> may need to wait for a while (like a few mins) for the existing probing
> activities to quiet down before observing the WARN_ON output.
>
> Thanks,
> --Martin
>