TCP connection repair (v3)

net/ipv4/tcp.c +3 -1

index 9e7f9ba..65ae921 100644
@@ -1935,7 +1935,9 @@ void tcp_close(struct sock *sk, long timeout)
  	 * advertise a zero window, then kill -9 the FTP client, wheee...
  	 * Note: timeout is always zero in such a case.
  	 */
-	if (data_was_unread) {
+	if (tcp_sk(sk)->repair) {
+		sk->sk_prot->disconnect(sk, 0);
+	} else if (data_was_unread) {
  		/* Unread data was tossed, zap the connection. */
  		NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
  		tcp_set_state(sk, TCP_CLOSE);

net/ipv4/tcp.c +7 -0

+	case TCP_REPAIR:
+		if (!tcp_can_repair_sock(sk))
+			err = -EPERM;
+		else if (val == 1) {
+			tp->repair = 1;
+			sk->sk_reuse = 2;
+			tp->repair_queue = TCP_NO_QUEUE;

Quoted 21 lines

net/ipv4/tcp.c +5 -1

index 9e7f9ba..65ae921 100644
@@ -1935,7 +1935,9 @@ void tcp_close(struct sock *sk, long timeout)
  	 * advertise a zero window, then kill -9 the FTP client, wheee...
  	 * Note: timeout is always zero in such a case.
  	 */
-	if (data_was_unread) {
+	if (tcp_sk(sk)->repair) {
+		sk->sk_prot->disconnect(sk, 0);
+	} else if (data_was_unread) {
  		/* Unread data was tossed, zap the connection. */
  		NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
  		tcp_set_state(sk, TCP_CLOSE);

@@ -2074,6 +2076,8 @@ int tcp_disconnect(struct sock *sk, int flags)
  	/* ABORT function of RFC793 */
  	if (old_state == TCP_LISTEN) {
  		inet_csk_listen_stop(sk);
+	} else if (unlikely(tp->repair)) {
+		sk->sk_err = ECONNABORTED;

net/ipv4/tcp.c int tcp_disconnect(struct sock *sk, int flags) · line 2083

Quoted 3 lines

net/ipv4/tcp.c +0 -0

  	} else if (tcp_need_reset(old_state) ||
  		   (tp->snd_nxt != tp->write_seq&&
  		(1<<  old_state)&  (TCPF_CLOSING | TCPF_LAST_ACK))) {

The patch looks good in general.
Single nitpick is that maybe you should be consistent in your use of unlikely. All of them seems equally unlikely, so I'd say you should wrap both.

Quoted 16 lines

net/ipv4/tcp.c +15 -0

+	case TCP_REPAIR:
+		if (!tcp_can_repair_sock(sk))
+			err = -EPERM;
+		else if (val == 1) {
+			tp->repair = 1;
+			sk->sk_reuse = 2;
+			tp->repair_queue = TCP_NO_QUEUE;
+		} else if (val == 0) {
+			tp->repair = 0;
+			sk->sk_reuse = 0;
+			tcp_send_window_probe(sk);
+		} else
+			err = -EINVAL;
+
+		break;

net/ipv4/tcp.c

Quoted 2 lines

net/ipv4/tcp.c +2 -0

+
+	case TCP_REPAIR_QUEUE:

Don't we need to test tcp_can_repair_sock() in all of them? I understand that TCP_REPAIR always comes before the other ones, so that means the socket is already in repair mode. But what should be the behavior in case the process drops privileges? Should it still be able to continue with the repair?

My first impression is that we need CAP_NET_ADMIN all along, so we should make sure it's there.

.

* Ability to forcibly bind a socket to a port

The sk->sk_reuse is set to 2 denoting, that the socket is question should be bound as if all the others in the system are configured with the SO_REUSEADDR option.

net/ipv4/tcp.c +0 -0

net/ipv4/tcp.c +4 -0

+			tp->repair_queue = val;
+		else
+			err = -EINVAL;
+		break;

On Wed, 2012-03-28 at 19:37 +0400, Pavel Emelyanov wrote:
[...]

Quoted 5 lines

* Ability to forcibly bind a socket to a port

The sk->sk_reuse is set to 2 denoting, that the socket is question should be bound as if all the others in the system are configured with the SO_REUSEADDR option.

Shouldn't this constant be named?

[...]

Quoted 2 lines

net/ipv4/tcp.c +0 -0

[...]

net/ipv4/tcp.c static int do_tcp_setsockopt(struct sock *sk, int level, · line 2329

Quoted 4 lines

net/ipv4/tcp.c +4 -0

+	case TCP_REPAIR_QUEUE:
+		if (!tp->repair)
+			err = -EPERM;
+		else if (val <= TCP_QUEUES_NR)

Off-by-one.

Quoted 4 lines

net/ipv4/tcp.c +4 -0

+			tp->repair_queue = val;
+		else
+			err = -EINVAL;
+		break;

[...]

Reading queues under repair mode is done with recvmsg call. The queue-under-repair set by TCP_REPAIR_QUEUE option is used to determine which queue should be read. Thus both send and receive queue can be read with this.

Caller must pass the MSG_PEEK flag.

Writing to queues is done with sendmsg call and yet again -- the repair-queue option can be used to push data into the receive queue.

When putting an skb into receive queue a zero tcp header is appented to its head to address the tcp_hdr(skb)->syn and the ->fin checks by the (after repair) tcp_recvmsg. These flags flags are both set to zero and that's why.

The fin cannot be met in the queue while reading the source socket, since the repair only works for closed/established sockets and queueing fin packet always changes its state.

The syn in the queue denotes that the respective skb's seq is "off-by-one" as compared to the actual payload lenght. Thus, at the rcv queue refill we can just drop this flag and set the skb's sequences to precice values. IOW -- emulate the situation when the packet with data and syn is splitted into two -- a packet with syn and a packet with data and the former one is already "eaten".

When the repair mode is turned off, the write queue seqs are updated so that the whole queue is considered to be 'already sent, waiting for ACKs' (write_seq = snd_nxt<= snd_una). From the protocol POV the send queue looks like it was sent, but the data between the write_seq and snd_nxt is lost in the network.

This helps to avoid another sockoption for setting the snd_nxt sequence. Leaving the whole queue in a 'not yet sent' state (as it will be after sendmsg-s) will not allow to receive any acks from the peer since the ack_seq will be after the snd_nxt. Thus even the ack for the window probe will be dropped and the connection will be 'locked' with the zero peer window.

Signed-off-by Pavel Emelyanov<[email protected]>

---
  net/ipv4/tcp.c        |   89 +++++++++++++++++++++++++++++++++++++++++++++++--
  net/ipv4/tcp_output.c |    1 +
  2 files changed, 87 insertions(+), 3 deletions(-)

net/ipv4/tcp.c +86 -3

index 65ae921..2ab3a31 100644
@@ -911,6 +911,39 @@ static inline int select_size(const struct sock *sk, bool sg)
  	return tmp;
  }
 
+static int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
+{
+	struct sk_buff *skb;
+	struct tcp_skb_cb *cb;
+	struct tcphdr *th;
+
+	skb = alloc_skb(size + sizeof(*th), sk->sk_allocation);
+	if (!skb)
+		goto err;
+
+	th = (struct tcphdr *)skb_put(skb, sizeof(*th));
+	skb_reset_transport_header(skb);
+	memset(th, 0, sizeof(*th));
+
+	if (memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size))
+		goto err_free;
+
+	cb = TCP_SKB_CB(skb);
+
+	TCP_SKB_CB(skb)->seq = tcp_sk(sk)->rcv_nxt;
+	TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + size;
+	TCP_SKB_CB(skb)->ack_seq = tcp_sk(sk)->snd_una - 1;
+
+	tcp_queue_rcv(sk, skb, sizeof(*th));
+
+	return size;
+
+err_free:
+	kfree_skb(skb);
+err:
+	return -ENOMEM;
+}
+
  int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
  		size_t size)
  {

@@ -932,6 +965,19 @@ int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
  		if ((err = sk_stream_wait_connect(sk,&timeo)) != 0)
  			goto out_err;
 
+	if (unlikely(tp->repair)) {
+		if (tp->repair_queue == TCP_RECV_QUEUE) {
+			copied = tcp_send_rcvq(sk, msg, size);
+			goto out;
+		}
+
+		err = -EINVAL;
+		if (tp->repair_queue == TCP_NO_QUEUE)
+			goto out_err;
+
+		/* 'common' sending to sendq */
+	}
+
  	/* This should be in poll */
  	clear_bit(SOCK_ASYNC_NOSPACE,&sk->sk_socket->flags);
 

@@ -1089,7 +1135,7 @@ new_segment:
  			if ((seglen -= copy) == 0&&  iovlen == 0)
  				goto out;
 
-			if (skb->len<  max || (flags&  MSG_OOB))
+			if (skb->len<  max || (flags&  MSG_OOB) || tp->repair)
  				continue;
 
  			if (forced_push(tp)) {

@@ -1102,7 +1148,7 @@ new_segment:
  wait_for_sndbuf:
  			set_bit(SOCK_NOSPACE,&sk->sk_socket->flags);
  wait_for_memory:
-			if (copied)
+			if (copied&&  !tp->repair)
  				tcp_push(sk, flags&  ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);
 
  			if ((err = sk_stream_wait_memory(sk,&timeo)) != 0)

@@ -1113,7 +1159,7 @@ wait_for_memory:
  	}
 
  out:
-	if (copied)
+	if (copied&&  !tp->repair)
  		tcp_push(sk, flags, mss_now, tp->nonagle);
  	release_sock(sk);
  	return copied;

@@ -1187,6 +1233,24 @@ static int tcp_recv_urg(struct sock *sk, struct msghdr *msg, int len, int flags)
  	return -EAGAIN;
  }
 
+static int tcp_peek_sndq(struct sock *sk, struct msghdr *msg, int len)
+{
+	struct sk_buff *skb;
+	int copied = 0, err = 0;
+
+	/* XXX -- need to support SO_PEEK_OFF */
+
+	skb_queue_walk(&sk->sk_write_queue, skb) {
+		err = skb_copy_datagram_iovec(skb, 0, msg->msg_iov, skb->len);
+		if (err)
+			break;
+
+		copied += skb->len;
+	}
+
+	return err ?: copied;
+}
+
  /* Clean up the receive buffer for full frames taken by the user,
   * then send an ACK if necessary.  COPIED is the number of bytes
   * tcp_recvmsg has given to the user so far, it speeds up the

@@ -1432,6 +1496,21 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
  	if (flags&  MSG_OOB)
  		goto recv_urg;
 
+	if (unlikely(tp->repair)) {
+		err = -EPERM;
+		if (!(flags&  MSG_PEEK))
+			goto out;
+
+		if (tp->repair_queue == TCP_SEND_QUEUE)
+			goto recv_sndq;
+
+		err = -EINVAL;
+		if (tp->repair_queue == TCP_NO_QUEUE)
+			goto out;
+
+		/* 'common' recv queue MSG_PEEK-ing */
+	}
+
  	seq =&tp->copied_seq;
  	if (flags&  MSG_PEEK) {
  		peek_seq = tp->copied_seq;

@@ -1783,6 +1862,10 @@ out:
  recv_urg:
  	err = tcp_recv_urg(sk, msg, len, flags);
  	goto out;
+
+recv_sndq:
+	err = tcp_peek_sndq(sk, msg, len);
+	goto out;
  }
  EXPORT_SYMBOL(tcp_recvmsg);
 

net/ipv4/tcp_output.c +1 -0

index 4e2ce39..b29d612 100644
@@ -2796,6 +2796,7 @@ void tcp_send_window_probe(struct sock *sk)
  {
  	if (sk->sk_state == TCP_ESTABLISHED) {
  		tcp_sk(sk)->snd_wl1 = tcp_sk(sk)->rcv_nxt - 1;
+		tcp_sk(sk)->snd_nxt = tcp_sk(sk)->write_seq;
  		tcp_xmit_probe_skb(sk, 0);
  	}
  }

Quoted 34 lines · Pavel Emelyanov

Reading queues under repair mode is done with recvmsg call. The queue-under-repair set by TCP_REPAIR_QUEUE option is used to determine which queue should be read. Thus both send and receive queue can be read with this.

Caller must pass the MSG_PEEK flag.

Writing to queues is done with sendmsg call and yet again -- the repair-queue option can be used to push data into the receive queue.

When putting an skb into receive queue a zero tcp header is appented to its head to address the tcp_hdr(skb)->syn and the ->fin checks by the (after repair) tcp_recvmsg. These flags flags are both set to zero and that's why.

The fin cannot be met in the queue while reading the source socket, since the repair only works for closed/established sockets and queueing fin packet always changes its state.

The syn in the queue denotes that the respective skb's seq is "off-by-one" as compared to the actual payload lenght. Thus, at the rcv queue refill we can just drop this flag and set the skb's sequences to precice values. IOW -- emulate the situation when the packet with data and syn is splitted into two -- a packet with syn and a packet with data and the former one is already "eaten".

When the repair mode is turned off, the write queue seqs are updated so that the whole queue is considered to be 'already sent, waiting for ACKs' (write_seq = snd_nxt<= snd_una). From the protocol POV the send queue looks like it was sent, but the data between the write_seq and snd_nxt is lost in the network.

Quoted 7 lines

This helps to avoid another sockoption for setting the snd_nxt sequence. Leaving the whole queue in a 'not yet sent' state (as it will be after sendmsg-s) will not allow to receive any acks from the peer since the ack_seq will be after the snd_nxt. Thus even the ack for the window probe will be dropped and the connection will be 'locked' with the zero peer window.

Do we need to restore various TCP options switch bits. e.g. window scale factor, sack_ok and so on.

En, I think the recorded mss_cache may be need to restored too.

Thanks.

Yu

Quoted 43 lines · Li Yu

Quoted 34 lines · Pavel Emelyanov

Reading queues under repair mode is done with recvmsg call. The queue-under-repair set by TCP_REPAIR_QUEUE option is used to determine which queue should be read. Thus both send and receive queue can be read with this.

Caller must pass the MSG_PEEK flag.

Writing to queues is done with sendmsg call and yet again -- the repair-queue option can be used to push data into the receive queue.

When putting an skb into receive queue a zero tcp header is appented to its head to address the tcp_hdr(skb)->syn and the ->fin checks by the (after repair) tcp_recvmsg. These flags flags are both set to zero and that's why.

The fin cannot be met in the queue while reading the source socket, since the repair only works for closed/established sockets and queueing fin packet always changes its state.

The syn in the queue denotes that the respective skb's seq is "off-by-one" as compared to the actual payload lenght. Thus, at the rcv queue refill we can just drop this flag and set the skb's sequences to precice values. IOW -- emulate the situation when the packet with data and syn is splitted into two -- a packet with syn and a packet with data and the former one is already "eaten".

When the repair mode is turned off, the write queue seqs are updated so that the whole queue is considered to be 'already sent, waiting for ACKs' (write_seq = snd_nxt<= snd_una). From the protocol POV the send queue looks like it was sent, but the data between the write_seq and snd_nxt is lost in the network.

Quoted 7 lines

This helps to avoid another sockoption for setting the snd_nxt sequence. Leaving the whole queue in a 'not yet sent' state (as it will be after sendmsg-s) will not allow to receive any acks from the peer since the ack_seq will be after the snd_nxt. Thus even the ack for the window probe will be dropped and the connection will be 'locked' with the zero peer window.

Quoted 2 lines

Do we need to restore various TCP options switch bits. e.g. window scale factor, sack_ok and so on.

SACK-s -- yes, this is in TODO list. Various window stuff -- not necessary. TCP will eventually negotiate proper values again.

Quoted 1 line

En, I think the recorded mss_cache may be need to restored too.

Same with mss. As far as I understand this one will be re-detected after a connection restore.

Quoted 3 lines

Thanks.

Yu

Quoted 43 lines · Li Yu

Quoted 34 lines · Pavel Emelyanov

Reading queues under repair mode is done with recvmsg call. The queue-under-repair set by TCP_REPAIR_QUEUE option is used to determine which queue should be read. Thus both send and receive queue can be read with this.

Caller must pass the MSG_PEEK flag.

Writing to queues is done with sendmsg call and yet again -- the repair-queue option can be used to push data into the receive queue.

When putting an skb into receive queue a zero tcp header is appented to its head to address the tcp_hdr(skb)->syn and the ->fin checks by the (after repair) tcp_recvmsg. These flags flags are both set to zero and that's why.

The fin cannot be met in the queue while reading the source socket, since the repair only works for closed/established sockets and queueing fin packet always changes its state.

The syn in the queue denotes that the respective skb's seq is "off-by-one" as compared to the actual payload lenght. Thus, at the rcv queue refill we can just drop this flag and set the skb's sequences to precice values. IOW -- emulate the situation when the packet with data and syn is splitted into two -- a packet with syn and a packet with data and the former one is already "eaten".

When the repair mode is turned off, the write queue seqs are updated so that the whole queue is considered to be 'already sent, waiting for ACKs' (write_seq = snd_nxt<= snd_una). From the protocol POV the send queue looks like it was sent, but the data between the write_seq and snd_nxt is lost in the network.

Quoted 7 lines

This helps to avoid another sockoption for setting the snd_nxt sequence. Leaving the whole queue in a 'not yet sent' state (as it will be after sendmsg-s) will not allow to receive any acks from the peer since the ack_seq will be after the snd_nxt. Thus even the ack for the window probe will be dropped and the connection will be 'locked' with the zero peer window.

Quoted 2 lines

Do we need to restore various TCP options switch bits. e.g. window scale factor, sack_ok and so on.

SACK-s -- yes, this is in TODO list. Various window stuff -- not necessary. TCP will eventually negotiate proper values again.

Quoted 1 line

En, I think the recorded mss_cache may be need to restored too.

Same with mss. As far as I understand this one will be re-detected after a connection restore.

Quoted 3 lines

Thanks.

Yu