netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Hunt <johunt@akamai.com>
To: subashab@codeaurora.org, Eric Dumazet <eric.dumazet@gmail.com>
Cc: Neal Cardwell <ncardwell@google.com>,
	Netdev <netdev@vger.kernel.org>,
	Yuchung Cheng <ycheng@google.com>
Subject: Re: Crash when receiving FIN-ACK in TCP_FIN_WAIT1 state
Date: Tue, 3 Dec 2019 09:24:34 -0800	[thread overview]
Message-ID: <f2016893-bf9e-3b65-4fe8-ff1bba4f4ced@akamai.com> (raw)
In-Reply-To: <0101016eba38455f-e79cd85a-a807-4309-bf3b-8a788135f3f2-000000@us-west-2.amazonses.com>

On 11/29/19 6:51 PM, subashab@codeaurora.org wrote:
>>>> Since tcp_write_queue_purge() calls tcp_rtx_queue_purge() and we're 
>>>> deleting everything in the retrans queue there, doesn't it make 
>>>> sense to zero out all of those associated counters? Obviously 
>>>> clearing sacked_out is helping here, but is there a reason to keep 
>>>> track of lost_out, retrans_out, etc if retrans queue is now empty? 
>>>> Maybe calling tcp_clear_retrans() from tcp_rtx_queue_purge() ?
>>>
>>> First, I would like to understand if we hit this problem on current 
>>> upstream kernels.
>>>
>>> Maybe a backport forgot a dependency.
>>>
>>> tcp_write_queue_purge() calls tcp_clear_all_retrans_hints(), not 
>>> tcp_clear_retrans(),
>>> this is probably for a reason.
>>>
>>> Brute force clearing these fields might hide a serious bug.
>>>
>>
>> I guess we are all too busy to get more understanding on this :/
> 
> Our test devices are on 4.19.x and it is not possible to switch to a newer
> version. Perhaps Josh has seen this on a newer kernel.

Sorry I've been out of town without email access. To be clear I've never 
seen this crash. I've only noticed that we do not clear some counters 
when we clear out the retransmit queue and this caught my eye when 
debugging another unrelated issue. I will try and get some cycles this 
week to instrument a kernel and reproduce the behavior I was seeing. My 
concern IIRC was more around tcp_left_out() being > packets_out and 
retrans_out causing tcp_packets_in_flight() to wrap. Anyway I'll report 
my findings on this thread if they seem relevant otherwise maybe I'll 
start another discussion thread. I don't want to pollute this one with 
my ramblings...

Josh

  parent reply	other threads:[~2019-12-03 17:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-20 20:25 Crash when receiving FIN-ACK in TCP_FIN_WAIT1 state Subash Abhinov Kasiviswanathan
2019-10-20 22:16 ` Neal Cardwell
2019-10-20 23:15   ` Subash Abhinov Kasiviswanathan
2019-10-21  1:20     ` Neal Cardwell
2019-10-21  2:45       ` Subash Abhinov Kasiviswanathan
2019-10-21 11:47         ` Neal Cardwell
2019-10-22  0:04           ` Subash Abhinov Kasiviswanathan
2019-10-22  1:28             ` Neal Cardwell
2019-10-29  1:36               ` Subash Abhinov Kasiviswanathan
2019-10-30 17:13                 ` Neal Cardwell
2019-10-30 18:27                   ` Subash Abhinov Kasiviswanathan
2019-10-30 21:48                     ` Josh Hunt
2019-10-31  1:27                       ` Eric Dumazet
2019-11-27  5:30                         ` Eric Dumazet
2019-11-30  2:51                           ` subashab
2019-11-30  5:39                             ` Avinash Patil
2019-12-02  2:23                               ` Eric Dumazet
     [not found]                           ` <0101016eba38455f-e79cd85a-a807-4309-bf3b-8a788135f3f2-000000@us-west-2.amazonses.com>
2019-12-03 17:24                             ` Josh Hunt [this message]
2019-10-31  0:38                     ` Eric Dumazet
2019-10-31  1:17                       ` Subash Abhinov Kasiviswanathan
2019-10-21 14:17 ` Eric Dumazet
2019-10-21 17:40   ` Subash Abhinov Kasiviswanathan
2019-10-21 18:10     ` Josh Hunt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2016893-bf9e-3b65-4fe8-ff1bba4f4ced@akamai.com \
    --to=johunt@akamai.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=subashab@codeaurora.org \
    --cc=ycheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).