Index: kern_timeout.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_timeout.c,v
retrieving revision 1.57
diff -u -p -r1.57 kern_timeout.c
--- kern_timeout.c	21 Nov 2019 17:57:40 -0000	1.57
+++ kern_timeout.c	23 Jan 2020 15:56:41 -0000
@@ -505,14 +505,25 @@ callout_wait(callout_impl_t *c, void *in
 	l = curlwp;
 	relock = NULL;
 	for (;;) {
+		/*
+		 * At this point we know the callout is not pending, but it
+		 * could be running on a CPU somewhere.  That can be curcpu
+		 * in a few cases:
+		 *
+		 * - curlwp is a higher priority soft interrupt
+		 * - the callout blocked on a lock and is currently asleep
+		 * - the callout itself has called callout_halt() (nice!)
+		 */
 		cc = c->c_cpu;
 		if (__predict_true(cc->cc_active != c || cc->cc_lwp == l))
 			break;
+
+		/* It's running - need to wait for it to complete. */
 		if (interlock != NULL) {
 			/*
 			 * Avoid potential scheduler lock order problems by
 			 * dropping the interlock without the callout lock
-			 * held.
+			 * held; then retry.
 			 */
 			mutex_spin_exit(lock);
 			mutex_exit(interlock);
@@ -529,7 +540,16 @@ callout_wait(callout_impl_t *c, void *in
 			    &sleep_syncobj);
 			sleepq_block(0, false);
 		}
+
+		/*
+		 * Re-lock the callout and check the state of play again. 
+		 * It's a common design pattern for callouts to re-schedule
+		 * themselves so put a stop to it again if needed.
+		 */
 		lock = callout_lock(c);
+		if ((c->c_flags & CALLOUT_PENDING) != 0)
+			CIRCQ_REMOVE(&c->c_list);
+		c->c_flags &= ~(CALLOUT_PENDING|CALLOUT_FIRED);
 	}
 
 	mutex_spin_exit(lock);