Bug 1690082

+++ This bug was initially created as a clone of Bug #1687899 +++

Description of problem:
There is a possible race condition inside gssproxy where one thread may call into epoll_wait(gpmctx->epollfd, ...) and while inside, a second thread may call close on (gpmctx->epollfd).  The thread inside epoll_wait is not woken up despite the second thread's close() operation but may hang inside epoll_wait().

We discovered this issue when studying a possible kernel bug where processes could hang indefinitely waiting for rpc.gssd upcall:
https://bugzilla.redhat.com/show_bug.cgi?id=1511706#c41

gpm_make_call() may release the mutex too early and as a result a thread race may be possible.

int gpm_make_call(int proc, union gp_rpc_arg *arg, union gp_rpc_res *res)
...
    /* grab the lock for the whole conversation */
    ret = gpm_grab_sock(gpmctx);
...    
    /* Send request, receive response with timeout */
    ret = gpm_send_recv_loop(gpmctx, send_buffer, send_length, &recv_buffer,
                             &recv_length);
    /* release the lock */
    gpm_release_sock(gpmctx);
    sockgrab = false;         // at this point some other thread could grab the lock and race with this one
...
done:
    gpm_timer_close(gpmctx);  // sets timerfd = -1 as seen in corefile
    gpm_epoll_close(gpmctx);  // sets epollfd = -1 as seen in corefile
...




Version-Release number of selected component (if applicable):
gssproxy-0.7.0-21.el7

How reproducible:
TBD - should be reproducible with delay inserted in gssproxy code

Steps to Reproduce:
See attached program which demonstrates the possibility of a hang inside epoll_wait()

Actual results:
gssproxy thread may hang inside epoll_wait() indefinitely

Expected results:
no indefinite hang inside epoll_wait() in gssproxy


Additional info:

Since this problem is so well defined and has a patch under testing, it makes sense to file this as a specific bug.