public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Devi Sandeep Endluri V V <dendluri@codeaurora•org>
To: Eric Dumazet <edumazet@google•com>
Cc: netdev <netdev@vger•kernel.org>,
	subashab@codeaurora•org, sharathv@codeaurora•org,
	ssaha@codeaurora•org, stranche@codeaurora•org
Subject: Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state
Date: Thu, 21 Feb 2019 16:31:20 +0530	[thread overview]
Message-ID: <20190221110118.GA24747@dendluri-linux.qualcomm.com> (raw)
In-Reply-To: <CANn89iJPgzWWor7YeGZvVH92gbJmD96Nwi=1pjfbXO8AgsjyNA@mail.gmail.com>

On Wed, Feb 20, 2019 at 07:47:59AM -0800, Eric Dumazet wrote:
> On Wed, Feb 20, 2019 at 6:28 AM Devi Sandeep Endluri V V
> <dendluri@codeaurora•org> wrote:
> >
> > Userspace sends tcp connection (sock) destroy on network permission
> > change. Kernel though doesn't send reset for the connections in
> > SYN-SENT state and these connections continue to remain. Even as
> > per RFC 793, there is no hard rule to not send RST on ABORT in
> > this state. Change to make sure RST are send for connections in
> > syn-sent state to avoid lingering connections on network switch.
> >
> > References from RFC 793
> >
> > ABORT Call
> >
> >         SYN-SENT STATE
> >
> >         All queued SENDs and RECEIVEs should be given "connection reset"
> >         notification, delete the TCB, enter CLOSED state, and return.
> >
> > SEGMENT ARRIVES
> >
> >         If the state is SYN-SENT then
> >         If the RST bit is set
> >
> >           If the ACK was acceptable then signal the user "error:
> >           connection reset", drop the segment, enter CLOSED state,
> >           delete TCB, and return.  Otherwise (no ACK) drop the segment
> >           and return.
> >
> > Signed-off-by: Devi Sandeep Endluri V V <dendluri@codeaurora•org>
> > ---
> >  net/ipv4/tcp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git net/ipv4/tcp.c net/ipv4/tcp.c
> > index cf3c509..8569dc5e 100644
> > --- net/ipv4/tcp.c
> > +++ net/ipv4/tcp.c
> > @@ -2495,7 +2495,7 @@ static inline bool tcp_need_reset(int state)
> >  {
> >         return (1 << state) &
> >                (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_FIN_WAIT1 |
> > -               TCPF_FIN_WAIT2 | TCPF_SYN_RECV);
> > +               TCPF_FIN_WAIT2 | TCPF_SYN_RECV | TCPF_SYN_SENT);
> >  }
> >
> >  static void tcp_rtx_queue_purge(struct sock *sk)
> 
> Hi
> 
> 1) I do not believe this patch is complete :
>    You have not changed tcp_disconnect() which seems to have dead code
> if we apply your patch.
> 
> 2) I am not sure we want to send yet another packet if the prior SYN
> packets elect no answer.
>   (It is not clear if your patch applies to this case)
> 
> 3) If we do not RESET, the other side has not seen the 3rd packet and
> should eventually exit from SYN_RECV state and die.
> 
> 4) A RESET can be lost on the network, and nothing will retransmit it.
> 
> Can you describe the use case more precisely, because it seems in
> contradiction of a feature that we plan to upstream.
> (TCP_SILENT_CLOSE : do not send flood of RST/FIN when a gigantic
> server process prematurely dies)
> 
> Thanks.

The algorithm for our network switch needs to have all TCP sessions
on the previous network cleaned up. So, we are trying to reset the
connections in SYN-SENT state as well. Is there any other way to
forcefully reset these connections immediately rather than waiting
for the other side to eventually exit and die?

  reply	other threads:[~2019-02-21 11:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190220142754.GA5073@dendluri-linux.qualcomm.com>
2019-02-20 15:47 ` [PATCH] tcp: Reset tcp connections in SYN-SENT state Eric Dumazet
2019-02-21 11:01   ` Devi Sandeep Endluri V V [this message]
2019-02-21 15:17     ` Eric Dumazet
2021-04-05 17:02 Manoj Basapathi
2021-04-09 16:52 ` 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=20190221110118.GA24747@dendluri-linux.qualcomm.com \
    --to=dendluri@codeaurora$(echo .)org \
    --cc=edumazet@google$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=sharathv@codeaurora$(echo .)org \
    --cc=ssaha@codeaurora$(echo .)org \
    --cc=stranche@codeaurora$(echo .)org \
    --cc=subashab@codeaurora$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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