Re: [PATCH net] tcp: fix forever orphan socket caused by tcp_abort

From: Jason Xing
Date: Wed Aug 14 2024 - 00:57:24 EST


On Wed, Aug 14, 2024 at 12:43 PM Lorenzo Colitti <lorenzo@xxxxxxxxxx> wrote:
>
> On Mon, Aug 5, 2024 at 4:23 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
> > > Each time we call inet_csk_destroy_sock(), we must make sure we've
> > > already set the state to TCP_CLOSE. Based on this, I think we can use
> > > this as an indicator to avoid calling twice to destroy the socket.
> >
> > I do not think this will work.
> >
> > With this patch, a listener socket will not get an error notification.
> >
> > Ideally we need tests for this seldom used feature.
>
> FWIW there is a fair amount of test coverage here:
>
> https://cs.android.com/android/platform/superproject/main/+/main:kernel/tests/net/test/sock_diag_test.py
>
> though unfortunately they don't pass on unmodified kernels (I didn't
> look into why - maybe Maciej knows). I ran the tests on the "v2-ish
> patch" and they all passed except for a test that expects that
> SOCK_DESTROY on a FIN_WAIT1 socket does nothing. That seems OK because
> it's the thing your patch is trying to fix.
>
> Just to confirm - it's OK to send a RST on a connection that's already
> in FIN_WAIT1 state? Is that allowed by the RFC?

I think so. Please take a look at the following link which tells us
whether we should send an RST:

ABORT Call

ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
CLOSE-WAIT STATE

Send a reset segment:

<SEQ=SND.NXT><CTL=RST>

All queued SENDs and RECEIVEs should be given "connection reset"
notification; all segments queued for transmission (except for the
RST formed above) or retransmission should be flushed, delete the
TCB, enter CLOSED state, and return.

https://www.ietf.org/rfc/rfc793.txt#:~:text=Specification%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20ABORT%20Call-,ABORT%20Call,-CLOSED%20STATE%20(i

Thanks,
Jason