andykimpe / rpms / 389-ds-base

Forked from rpms/389-ds-base 5 months ago
Clone

Blame SOURCES/0031-Ticket-49410-opened-connection-can-remain-no-longer-.patch

081b2d
From 11cea14acfc11d0328013b61a3e1396e97dfe577 Mon Sep 17 00:00:00 2001
8a4a2a
From: Thierry Bordaz <tbordaz@redhat.com>
081b2d
Date: Tue, 14 Nov 2017 16:29:03 +0100
8a4a2a
Subject: [PATCH] Ticket 49410 - opened connection can remain no longer poll,
8a4a2a
 like hanging
8a4a2a
8a4a2a
Bug Description:
081b2d
	Some opened connection are no longer poll.
081b2d
	Those connections has 'gettingber' toggle set although there is
081b2d
	no more worker thread reading it.
081b2d
	The reason they have gettingber set is that the last
081b2d
	operation had 'persistent search' flag. With such flag
081b2d
	gettingber is not reset.
081b2d
	persistent flag is set even when no persistent search/sync_repl
081b2d
	was received on the connection.
081b2d
	The problem is that the flag is tested on the wrong operation.
081b2d
	The tested operation can be
081b2d
		- the first operation when the connection entered in turbo mode
081b2d
		- the previous operation if several ops PDUs were read on the network
081b2d
		- accessing random memory
081b2d
081b2d
	In theory testing the flag can lead to sigsev even
081b2d
	if it never crash
8a4a2a
8a4a2a
Fix Description:
081b2d
	The fix is to use the operation that is in the pblock
081b2d
	In such case pb_op is no longer used, so we can get rid of it.
081b2d
	In addition make pb_conn a local variable where it is used
8a4a2a
8a4a2a
https://pagure.io/389-ds-base/issue/49410
8a4a2a
8a4a2a
Reviewed by: Ludwig Krispenz, Mark Reynolds
8a4a2a
8a4a2a
Platforms tested: F26
8a4a2a
8a4a2a
Flag Day: no
8a4a2a
8a4a2a
Doc impact: no
8a4a2a
---
081b2d
 ldap/servers/slapd/connection.c | 7 +++----
081b2d
 1 file changed, 3 insertions(+), 4 deletions(-)
8a4a2a
8a4a2a
diff --git a/ldap/servers/slapd/connection.c b/ldap/servers/slapd/connection.c
081b2d
index 24a7a1c05..3f19b9765 100644
8a4a2a
--- a/ldap/servers/slapd/connection.c
8a4a2a
+++ b/ldap/servers/slapd/connection.c
081b2d
@@ -1498,8 +1498,6 @@ connection_threadmain()
081b2d
     int maxthreads = 0;
081b2d
     int enable_nunc_stans = 0;
081b2d
     long bypasspollcnt = 0;
081b2d
-    Connection *pb_conn = NULL;
081b2d
-    Operation *pb_op = NULL;
081b2d
 
081b2d
     enable_nunc_stans = config_get_enable_nunc_stans();
081b2d
 #if defined(hpux)
081b2d
@@ -1520,6 +1518,8 @@ connection_threadmain()
081b2d
         }
8a4a2a
 
081b2d
         if (!thread_turbo_flag && !more_data) {
081b2d
+	    Connection *pb_conn = NULL;
8a4a2a
+
081b2d
             /* If more data is left from the previous connection_read_operation,
081b2d
                we should finish the op now.  Client might be thinking it's
081b2d
                done sending the request and wait for the response forever.
081b2d
@@ -1530,7 +1530,6 @@ connection_threadmain()
081b2d
              * Connection wait for new work provides the conn and op for us.
081b2d
              */
081b2d
             slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn);
081b2d
-            slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op);
081b2d
 
081b2d
             switch (ret) {
081b2d
             case CONN_NOWORK:
081b2d
@@ -1786,7 +1785,7 @@ connection_threadmain()
081b2d
         /* total number of ops for the server */
081b2d
         slapi_counter_increment(ops_completed);
081b2d
         /* If this op isn't a persistent search, remove it */
081b2d
-        if (pb_op->o_flags & OP_FLAG_PS) {
081b2d
+        if (op->o_flags & OP_FLAG_PS) {
081b2d
             PR_EnterMonitor(conn->c_mutex);
081b2d
             connection_release_nolock(conn); /* psearch acquires ref to conn - release this one now */
081b2d
             PR_ExitMonitor(conn->c_mutex);
8a4a2a
-- 
8a4a2a
2.13.6
8a4a2a