pseudo: Add fastop reply fix

This changes the pseudo FASTOP functionality so that a reply to the
operation is required. This means we then cannot lose data if a connection
is closed. This in turn stops corruption if we run out of file handles
and have to close connections.

This tweaks the connection closure patch to update the comment there which
is now outdated.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

3 files changed, 80 insertions, 6 deletions

diff --git a/meta/recipes-devtools/pseudo/files/fastopreply.patch b/meta/recipes-devtools/pseudo/files/fastopreply.patch
new file mode 100644
index 0000000000..904c2d04e6
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/fastopreply.patch
@@ -0,0 +1,76 @@
+Ensure FASTOP messages get an ACK reply so that the client can be sure the server
+recieved them. This means if connections are terminated, data isn't lost.
+
+RP 2017/9/22
+
+Upstream-Status: Submitted
+
+Index: pseudo-1.8.2/pseudo_client.c
+===================================================================
+--- pseudo-1.8.2.orig/pseudo_client.c
++++ pseudo-1.8.2/pseudo_client.c
+@@ -1331,21 +1331,19 @@ pseudo_client_request(pseudo_msg_t *msg,
+ 		 * indicating a successful send.
+ 		 */
+ 		pseudo_debug(PDBGF_CLIENT | PDBGF_VERBOSE, "sent!\n");
+-		if (msg->type != PSEUDO_MSG_FASTOP) {
+-			response = pseudo_msg_receive(connect_fd);
+-			if (!response) {
+-				pseudo_debug(PDBGF_CLIENT, "expected response did not occur; retrying\n");
++		response = pseudo_msg_receive(connect_fd);
++		if (!response) {
++			pseudo_debug(PDBGF_CLIENT, "expected response did not occur; retrying\n");
++		} else {
++			if (response->type != PSEUDO_MSG_ACK) {
++				pseudo_debug(PDBGF_CLIENT, "got non-ack response %d\n", response->type);
++				return 0;
++			} else if (msg->type != PSEUDO_MSG_FASTOP) {
++				pseudo_debug(PDBGF_CLIENT | PDBGF_VERBOSE, "got response type %d\n", response->type);
++				return response;
+ 			} else {
+-				if (response->type != PSEUDO_MSG_ACK) {
+-					pseudo_debug(PDBGF_CLIENT, "got non-ack response %d\n", response->type);
+-					return 0;
+-				} else {
+-					pseudo_debug(PDBGF_CLIENT | PDBGF_VERBOSE, "got response type %d\n", response->type);
+-					return response;
+-				}
++				return 0;
+ 			}
+-		} else {
+-			return 0;
+ 		}
+ 	}
+ 	pseudo_diag("pseudo: server connection persistently failed, aborting.\n");
+Index: pseudo-1.8.2/pseudo_server.c
+===================================================================
+--- pseudo-1.8.2.orig/pseudo_server.c
++++ pseudo-1.8.2/pseudo_server.c
+@@ -463,6 +463,11 @@ close_client(int client) {
+ 			--highest_client;
+ }
+ 
++static pseudo_msg_t server_fastop_reply = { 
++        .type = PSEUDO_MSG_ACK,
++        .op = OP_NONE,
++};
++
+ /* Actually process a request.
+  */
+ static int
+@@ -515,8 +520,14 @@ serve_client(int i) {
+ 		 * pseudo_server_response.
+ 		 */
+ 		if (in->type != PSEUDO_MSG_SHUTDOWN) {
+-                        if (in->type == PSEUDO_MSG_FASTOP)
++                        if (in->type == PSEUDO_MSG_FASTOP) {
+                                 send_response = 0;
++                                /* For fastops we reply now to say we got the data */
++                                if ((rc = pseudo_msg_send(clients[i].fd, &server_fastop_reply, 0, NULL)) != 0) {
++                                            pseudo_debug(PDBGF_SERVER, "failed to send fastop ack to client %d [%d]: %d (%s)\n",
++                                                    i, (int) clients[i].pid, rc, strerror(errno));
++                                }
++                        }
+ 			/* most messages don't need these, but xattr may */
+ 			response_path = 0;
+ 			response_pathlen = -1;
diff --git a/meta/recipes-devtools/pseudo/files/toomanyfiles.patch b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
index 7319ab29bf..b085a4505d 100644
--- a/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
+++ b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
@@ -9,7 +9,7 @@ a small risk of data loss here sadly but its better than hanging.
 RP
 2017/4/25
 
-Upstream-Status: Pending [Peter is aware of the issue]
+Upstream-Status: Submitted [Peter is aware of the issue]
 
 Index: pseudo-1.8.2/pseudo_server.c
 ===================================================================
@@ -31,15 +31,12 @@ Index: pseudo-1.8.2/pseudo_server.c
  
  	pseudo_debug(PDBGF_SERVER, "server loop started.\n");
  	if (listen_fd < 0) {
-@@ -663,10 +665,18 @@ pseudo_server_loop(void) {
+@@ -663,10 +665,15 @@ pseudo_server_loop(void) {
  						message_time.tv_usec -= 1000000;
  						++message_time.tv_sec;
  					}
 +				} else if (hitmaxfiles) {
-+					/* In theory there is a potential race here where if we close a client, 
-+					   it may have sent us a fastop message which we don't act upon.
-+					   If we don't close a filehandle we'll loop indefinitely thought. 
-+					   Only close one per loop iteration in the interests of caution */
++					/* Only close one per loop iteration in the interests of caution */
 +					close_client(i);
 +					hitmaxfiles = 0;
  				}
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
index 81853e95c4..73ef57231a 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
@@ -7,6 +7,7 @@ SRC_URI = "http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz
            file://moreretries.patch \
            file://efe0be279901006f939cd357ccee47b651c786da.patch \
            file://b6b68db896f9963558334aff7fca61adde4ec10f.patch \
+           file://fastopreply.patch \
            file://toomanyfiles.patch \
            file://0001-Use-epoll-API-on-Linux.patch \
            "