Commit
6ad3d646 (rx: Correctly test for end of call queue) fixed a
broken end-of-queue check in rx_GetCall, but it only fixed the
RX_ENABLE_LOCKS version of rx_GetCall. The non-locks version (i.e. the
LWP version) still had this bug. Fix it for the LWP case, to avoid
some rare cases where an Rx call can get stuck in the incoming queue.
Also remove the comment added by commit
170dbb3c (rx: Use opr queues),
since we're fixing the mentioned problem.
Reviewed-on: https://gerrit.openafs.org/13880
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit
d9fc4890f01a41fa5a63f97f2446b3afc35b473f)
Change-Id: I2e0106b63a8bf09634500944490dfae2e86c18b9
Reviewed-on: https://gerrit.openafs.org/13892
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
service = tcall->conn->service;
if (QuotaOK(service)) {
MUTEX_ENTER(&rx_pthread_mutex);
- /* XXX - If tcall->entry.next is NULL, then we're no longer
- * on a queue at all. This shouldn't happen. */
- if (tno == rxi_fcfs_thread_num || !tcall->entry.next) {
+ if (tno == rxi_fcfs_thread_num
+ || opr_queue_IsEnd(&rx_incomingCallQueue, cursor)) {
MUTEX_EXIT(&rx_pthread_mutex);
/* If we're the fcfs thread, then we'll just use
* this call. If we haven't been able to find an optimal