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

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