[gnome-continuous-yocto/gnomeostree-3.28-rocko: 6374/8267] pseudo: Handle too many files deadlock
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 6374/8267] pseudo: Handle too many files deadlock
- Date: Sun, 17 Dec 2017 04:45:18 +0000 (UTC)
commit 8cbdc270c9663bcdc314fec19de51e85a6461a94
Author: Richard Purdie <richard purdie linuxfoundation org>
Date: Tue Apr 25 15:25:54 2017 +0100
pseudo: Handle too many files deadlock
If we have large amounts of parallelism, pseudo can end up with too
many open connections and will no longer accept further connections,
hanging. This patch works around that by closing some clients, allowing
turnover of connections and unblocking the system. The downside is a small
but theoretical window of data loss. This is likely better than locking
up entirely though. Discussions with Peter are onging about how we could
better fix this.
(From OE-Core rev: f3589f154dad1c92e599737623d392508810ae7e)
Signed-off-by: Richard Purdie <richard purdie linuxfoundation org>
.../pseudo/files/toomanyfiles.patch | 62 ++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.8.2.bb | 1 +
2 files changed, 63 insertions(+), 0 deletions(-)
---
diff --git a/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
new file mode 100644
index 0000000..7319ab2
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/toomanyfiles.patch
@@ -0,0 +1,62 @@
+Currently if we max out the maximum number of files, pseudo can deadlock, unable to
+accept new connections yet unable to move forward and unblock the other processes
+waiting either.
+
+Rather than hang, when this happens, close out inactive connections, allowing us
+to accept the new ones. The disconnected clients will simply reconnect. There is
+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]
+
+Index: pseudo-1.8.2/pseudo_server.c
+===================================================================
+--- pseudo-1.8.2.orig/pseudo_server.c
++++ pseudo-1.8.2/pseudo_server.c
+@@ -581,6 +581,7 @@ pseudo_server_loop(void) {
+ int rc;
+ int fd;
+ int loop_timeout = pseudo_server_timeout;
++ int hitmaxfiles;
+
+ clients = malloc(16 * sizeof(*clients));
+
+@@ -597,6 +598,7 @@ pseudo_server_loop(void) {
+ active_clients = 1;
+ max_clients = 16;
+ highest_client = 0;
++ hitmaxfiles = 0;
+
+ pseudo_debug(PDBGF_SERVER, "server loop started.\n");
+ if (listen_fd < 0) {
+@@ -663,10 +665,18 @@ 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 */
++ close_client(i);
++ hitmaxfiles = 0;
+ }
+ if (die_forcefully)
+ break;
+ }
++ hitmaxfiles = 0;
+ if (!die_forcefully &&
+ (FD_ISSET(clients[0].fd, &events) ||
+ FD_ISSET(clients[0].fd, &reads))) {
+@@ -688,6 +698,9 @@ pseudo_server_loop(void) {
+ */
+ pseudo_server_timeout = DEFAULT_PSEUDO_SERVER_TIMEOUT;
+ die_peacefully = 0;
++ } else if (errno == EMFILE) {
++ hitmaxfiles = 1;
++ pseudo_debug(PDBGF_SERVER, "Hit max open files, dropping a
client.\n");
+ }
+ }
+ pseudo_debug(PDBGF_SERVER, "server loop complete [%d clients left]\n",
active_clients);
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb b/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb
index b427b9a..9bcd031 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://toomanyfiles.patch \
"
SRC_URI[md5sum] = "7d41e72188fbea1f696c399c1a435675"
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]