[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKD1Yr3i+858zNvSwbuFLiBHS52xhTw5oh6P-sPgRNcMbWEbhw@mail.gmail.com>
Date: Wed, 14 Aug 2024 16:34:51 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Xueming Feng <kuro@...oa.me>
Cc: "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>, Jason Xing <kerneljasonxing@...il.com>,
Neal Cardwell <ncardwell@...gle.com>, Yuchung Cheng <ycheng@...gle.com>,
Soheil Hassas Yeganeh <soheil@...gle.com>, David Ahern <dsahern@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net,v2] tcp: fix forever orphan socket caused by tcp_abort
On Mon, Aug 12, 2024 at 7:53 PM Xueming Feng <kuro@...oa.me> wrote:
> The -ENOENT code comes from the associate patch Lorenzo made for
> iproute2-ss; link attached below.
ENOENT does seem reasonable. It's the same thing that would happen if
userspace passed in a nonexistent cookie (we have a test for that).
I'd guess this could happen if userspace was trying to destroy a
socket but it lost the race against the process owning a socket
closing it?
> bh_unlock_sock(sk);
> local_bh_enable();
> - tcp_write_queue_purge(sk);
Is this not necessary in any other cases? What if there is
retransmitted data, shouldn't that be cleared?
Other than that, I have run the Android tests on this patch and they
all passed other than the test that checks that closing FIN_WAIT1
sockets can't be closed. That's expected to fail because it checking
that the kernel does not support what you are trying to support. I
uploaded a CL to fix that: https://r.android.com/3217682 .
Tested-By: Lorenzo Colitti <lorenzo@...gle.com>
Powered by blists - more mailing lists