From: Lorenzo Colitti <lorenzo@google.com>
To: 배석진 <soukjin.bae@samsung.com>
Cc: "Eric Dumazet" <eric.dumazet@gmail.com>,
netdev@vger.kernel.org, 유금환 <geumhwan.yu@samsung.com>,
"Maciej Żenczykowski" <zenczykowski@gmail.com>
Subject: Re: (2) FW: [Resource Leak] Suggesting patch for tcp_close
Date: Tue, 27 Nov 2018 23:36:06 -0800 [thread overview]
Message-ID: <CAKD1Yr14r6rGL8O9oofP9yQRN-i14HwG7nR2TNc4ua4eAfPrVg@mail.gmail.com> (raw)
In-Reply-To: <20181128061715epcms1p18e21f112dea8cdf67481c35af52419bd@epcms1p1>
On Tue, Nov 27, 2018 at 10:17 PM 배석진 <soukjin.bae@samsung.com> wrote:
> >> we saw hundreds of not closed tcp session with FIN_WAIT1 and LAST_ACK.
> >
> > These sessions should have a timer, and eventually disappear.
>
> FIN_WAIT2 and TIME_WAIT have a timer.
> but FIN_WAIT1 and LAST_ACK are have too?
What harm is caused by these stale sessions? I thought that was the
intended behaviour.
If you look at the original design discussions that led to the
SOCK_DESTROY and tcp_abort patch, the goal of SOCK_DESTROY was not
primarily to clear TCP state, but primarily to unblock applications
that were stuck in blocking socket operations such as read(), write()
and connect. That is the reason why it only calls tcp_done if the
SOCK_DEAD flag is not set. See in particular
https://www.spinics.net/lists/netdev/msg352716.html , where opposition
was voiced to being able to close sockets in TIME_WAIT_STATE. That
said, I don't have a strong opinion on this: whatever works for Eric
works for me.
> > Do you have a test to demonstrate the issue ?
> >
> > I know Lorenzo wrote tests, so presumably new tests are needed.
There are definitely tests that check that SOCK_DESTROY does nothing
for dead sockets (i.e., the current behaviour without this patch).
Those tests are part of the Android conformance test suites (VTS), so
I think taking this patch will cause the device to fail the Android
conformance here:
https://cs.corp.google.com/android/kernel/tests/net/test/sock_diag_test.py?l=663
Soukjin, you will need to modify that test if this patch is applied.
next prev parent reply other threads:[~2018-11-28 18:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20181123072258epcms1p8c41425598751be28f8cc05b91c7ac4b5@epcms1p8>
2018-11-23 7:22 ` Suggesting patch for tcp_close 배석진
[not found] ` <CGME20181123072258epcms1p8c41425598751be28f8cc05b91c7ac4b5@epcms1p7>
2018-11-28 1:09 ` FW: [Resource Leak] " 배석진
2018-11-28 4:57 ` Eric Dumazet
2018-11-28 4:58 ` Eric Dumazet
[not found] ` <CGME20181123072258epcms1p8c41425598751be28f8cc05b91c7ac4b5@epcms1p1>
2018-11-28 6:17 ` 배석진
2018-11-28 7:36 ` Lorenzo Colitti [this message]
[not found] ` <CGME20181123072258epcms1p8c41425598751be28f8cc05b91c7ac4b5@epcms1p6>
2018-11-28 8:49 ` RE:(2) (2) " 배석진
2018-11-28 14:40 ` Eric Dumazet
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=CAKD1Yr14r6rGL8O9oofP9yQRN-i14HwG7nR2TNc4ua4eAfPrVg@mail.gmail.com \
--to=lorenzo@google.com \
--cc=eric.dumazet@gmail.com \
--cc=geumhwan.yu@samsung.com \
--cc=netdev@vger.kernel.org \
--cc=soukjin.bae@samsung.com \
--cc=zenczykowski@gmail.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).