mirror of
				https://github.com/torvalds/linux.git
				synced 2025-11-04 10:40:15 +02:00 
			
		
		
		
	SUNRPC: Fix a race to wake a sync task
We've observed NFS clients with sync tasks sleeping in __rpc_execute waiting on RPC_TASK_QUEUED that have not responded to a wake-up from rpc_make_runnable(). I suspect this problem usually goes unnoticed, because on a busy client the task will eventually be re-awoken by another task completion or xprt event. However, if the state manager is draining the slot table, a sync task missing a wake-up can result in a hung client. We've been able to prove that the waker in rpc_make_runnable() successfully calls wake_up_bit() (ie- there's no race to tk_runstate), but the wake_up_bit() call fails to wake the waiter. I suspect the waker is missing the load of the bit's wait_queue_head, so waitqueue_active() is false. There are some very helpful comments about this problem above wake_up_bit(), prepare_to_wait(), and waitqueue_active(). Fix this by inserting smp_mb__after_atomic() before the wake_up_bit(), which pairs with prepare_to_wait() calling set_current_state(). Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
This commit is contained in:
		
							parent
							
								
									a308996ed7
								
							
						
					
					
						commit
						ed0172af5d
					
				
					 1 changed files with 3 additions and 1 deletions
				
			
		| 
						 | 
				
			
			@ -369,8 +369,10 @@ static void rpc_make_runnable(struct workqueue_struct *wq,
 | 
			
		|||
	if (RPC_IS_ASYNC(task)) {
 | 
			
		||||
		INIT_WORK(&task->u.tk_work, rpc_async_schedule);
 | 
			
		||||
		queue_work(wq, &task->u.tk_work);
 | 
			
		||||
	} else
 | 
			
		||||
	} else {
 | 
			
		||||
		smp_mb__after_atomic();
 | 
			
		||||
		wake_up_bit(&task->tk_runstate, RPC_TASK_QUEUED);
 | 
			
		||||
	}
 | 
			
		||||
}
 | 
			
		||||
 | 
			
		||||
/*
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in a new issue