[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1210221251520.1684@cleese>
Date: Mon, 22 Oct 2012 13:00:01 -0700 (PDT)
From: Vijay Subramanian <subramanian.vijay@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: Vijay Subramanian <subramanian.vijay@...il.com>,
enh <enh@...gle.com>,
Venkat Venkatsubra <venkat.x.venkatsubra@...cle.com>,
netdev@...r.kernel.org
Subject: Re: listen(2) backlog changes in or around Linux 3.1?
>
> If we send a SYNACK, then receive the ACK from client, and the acceptq
> is full, we should reset the connexion. Right now we have kind of stupid
> situation, were we drop the ACK, and leave the REQ in the SYN_RECV
> state, so we retransmit SYNACKS.
>
It seems the third ack is remembered in inet_rsk(req)->acked in
tcp_check_req(). However, because of the order in which the tests are performed,
server stills retransmits the synack needlessly. Following patch
(for review) prevents this synack retransmission if third ack has been
received.
The request_sock will expire in around 30 seconds and will be dropped if it does
not move into accept_queue by then. Maybe we should also call
req->rsk_ops->send_reset(sk,skb);
when the request_sock expires and is dropped?
net/ipv4/inet_connection_sock.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index d34ce29..4e8e52e 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -598,9 +598,8 @@ void inet_csk_reqsk_queue_prune(struct sock *parent,
&expire, &resend);
req->rsk_ops->syn_ack_timeout(parent, req);
if (!expire &&
- (!resend ||
- !req->rsk_ops->rtx_syn_ack(parent, req, NULL) ||
- inet_rsk(req)->acked)) {
+ (!resend || inet_rsk(req)->acked ||
+ !req->rsk_ops->rtx_syn_ack(parent, req, NULL))) {
unsigned long timeo;
if (req->retrans++ == 0)
Thanks,
Vijay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists