From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
To: Neal Cardwell <ncardwell@google.com>
Cc: Netdev <netdev@vger.kernel.org>,
Yuchung Cheng <ycheng@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: Crash when receiving FIN-ACK in TCP_FIN_WAIT1 state
Date: Sun, 20 Oct 2019 17:15:49 -0600 [thread overview]
Message-ID: <f7a0507ce733dd722b1320622dfd1caa@codeaurora.org> (raw)
In-Reply-To: <CADVnQynFeJCpv4irANd8O63ck0ewUq66EDSHHRKdv-zieGZ+UA@mail.gmail.com>
> Hmm. Random related thought while searching for a possible cause: I
> wonder if tcp_write_queue_purge() should clear tp->highest_sack (and
> possibly tp->sacked_out)? The tcp_write_queue_purge() code is careful
> to call tcp_clear_all_retrans_hints(tcp_sk(sk)) and I would imagine
> that similar considerations would imply that we should clear at least
> tp->highest_sack?
>
> neal
Hi Neal
If the socket is in FIN-WAIT1, does that mean that all the segments
corresponding to SACK blocks are sent and ACKed already?
tp->sacked_out is non zero in all these crashes (is the SACK information
possibly invalid or stale here?).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2019-10-20 23:15 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 [this message]
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
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=f7a0507ce733dd722b1320622dfd1caa@codeaurora.org \
--to=subashab@codeaurora.org \
--cc=eric.dumazet@gmail.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.