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

6f51e1
From 72f541fd317321fbd0395dcaa77830aa8b5d35b6 Mon Sep 17 00:00:00 2001
8a4a2a
From: Thierry Bordaz <tbordaz@redhat.com>
6f51e1
Date: Wed, 15 Nov 2017 16:38:28 +0100
8a4a2a
Subject: [PATCH] Ticket 49410 - opened connection can remain no longer poll,
8a4a2a
 like hanging
8a4a2a
8a4a2a
Bug Description:
6f51e1
    Some opened connection are no longer poll.
6f51e1
    Those connections has 'gettingber' toggle set although there is
6f51e1
    no more worker thread reading it.
6f51e1
    The reason they have gettingber set is that the last
6f51e1
    operation had 'persistent search' flag. With such flag
6f51e1
    gettingber is not reset.
6f51e1
    persistent flag is set even when no persistent search/sync_repl
6f51e1
    was received on the connection.
6f51e1
    The problem is that the flag is tested on the wrong operation.
6f51e1
    The tested operation can be
6f51e1
        - the first operation when the connection entered in turbo mode
6f51e1
        - the previous operation if several ops PDUs were read on the network
6f51e1
        - accessing random memory
6f51e1
6f51e1
    In theory testing the flag can lead to sigsev even
6f51e1
    if it never crash
8a4a2a
8a4a2a
Fix Description:
6f51e1
    The fix is to use the operation that is in the pblock
6f51e1
    In such case pb_op is no longer used, so we can get rid of it.
6f51e1
    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
---
6f51e1
 ldap/servers/slapd/connection.c | 2 ++
6f51e1
 1 file changed, 2 insertions(+)
8a4a2a
8a4a2a
diff --git a/ldap/servers/slapd/connection.c b/ldap/servers/slapd/connection.c
6f51e1
index 359b59a4d..c00c88578 100644
8a4a2a
--- a/ldap/servers/slapd/connection.c
8a4a2a
+++ b/ldap/servers/slapd/connection.c
6f51e1
@@ -1540,6 +1540,8 @@ connection_threadmain()
6f51e1
 		}
8a4a2a
 
6f51e1
 		if (!thread_turbo_flag && !more_data) {
6f51e1
+			Connection *pb_conn = NULL;
8a4a2a
+
6f51e1
 			/* If more data is left from the previous connection_read_operation,
6f51e1
 			   we should finish the op now.  Client might be thinking it's
6f51e1
 			   done sending the request and wait for the response forever.
8a4a2a
-- 
8a4a2a
2.13.6
8a4a2a