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

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