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

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