once cvs's flow-control mechanism has kicked in, stop reading from

its local reader until memory usage goes back down below its
watermark.

during a checkout of a tree with big files (like www) from a fast
reader (disk) and a slow writer (net), the amount of data being
buffered can back up enough that cvs tries to allocate too many
buffers and hits its resource limit, causing death.

cvs's flow-control mechanism properly detects this early on, but the
message sent to the reader process to stop sending data takes too
long to process.

take more aggressive action and just stop reading from the reader
until the writer has ejected enough data that it can start re-using
its already-allocated buffers instead of allocating new ones.

ok deraadt

1 files changed, 5 insertions, 1 deletions

diff --git a/gnu/usr.bin/cvs/src/server.c b/gnu/usr.bin/cvs/src/server.c
index dee5b5d36ea..f0d30c0e94f 100644
--- a/gnu/usr.bin/cvs/src/server.c
+++ b/gnu/usr.bin/cvs/src/server.c
@@ -3072,7 +3072,11 @@ error  \n");
 	    {
 		FD_SET (stderr_pipe[0], &readfds);
 	    }
-	    if (protocol_pipe[0] >= 0)
+	    if (protocol_pipe[0] >= 0
+#ifdef SERVER_FLOWCONTROL
+	    && !have_flowcontrolled
+#endif
+	    )
 	    {
 		FD_SET (protocol_pipe[0], &readfds);
 	    }