Version: 1
-Previous: 0638eb9abb59cfc0ff566610be10a29d33e9b20f
-Head: fe96820b3ec697c0600f29ee483f98a83b4d9f2b
+Previous: 2d6a9293af412ec0ec6649f7d2091c503aba7af9
+Head: 86520b86ffb45d3caf6e5bd94271f99deef0a5f9
Applied:
- shutdown: 2a96a8bfe5195430d01da440c53475aae7ec521f
- refresh-temp: fe96820b3ec697c0600f29ee483f98a83b4d9f2b
+ shutdown: 86520b86ffb45d3caf6e5bd94271f99deef0a5f9
Unapplied:
old-af-ib: d71ebf70cf74111cfd5f0982d9abe6ec68fb38e3
old-seterr: 47eb0c419687c2690292c1910acae83a46e5388c
+++ /dev/null
-Bottom: 75b04ca01637eeac4f5b673a12c87917a9126271
-Top: 75b04ca01637eeac4f5b673a12c87917a9126271
-Author: Sean Hefty <sean.hefty@intel.com>
-Date: 2013-11-06 18:56:21 -0800
-
-Refresh of shutdown
-
----
-
-
rsockets: Handle race between rshutdown and rpoll
+Multi-threaded applications which call rpoll and rshutdown
+simultaneously can hang. Ceph developers reported an issue
+with the rsocket implementation. Ceph calls rpoll in
+one thread, and while that thread is blocked in rpoll,
+a second thread may cann rshutdown on the socket. In
+normal sockets, this results in the poll call unblocking
+(since a call to read on the socket will no longer block).
+however, rsockets does not free the thread blocked on the
+rpoll call.
+
+To fix this, we add some additional state checking to
+protect against threads calling rpoll and rshutdown
+simultaneously. We also have the rshutdown call
+transition the QP into an error state. This causes all
+posted receives to complete as flushed, which results
+in unblocking the thread in rpoll (to process the flushed
+receives).
+
Signed-off-by: Sean Hefty <sean.hefty@intel.com>