[PATCH] um: time-travel: fix sched_yield() behaviour

[Johannes Berg <johannes@sipsolutions.net>]

From: Johannes Berg <johannes.berg@intel.com>

Just incrementing tt_extra_sched_jiffies can make this
drift enough to hit the softlockup detector, e.g. with
ping using sched_yield() in a loop to measure short
intervals. Make the simulation actually pass time, this
requires going to the external scheduler but actually
makes this sort of thing behave much better and avoids
the soft lockup.

Fixes: 887c5c12e80c ("um: work around sched_yield not yielding in time-travel mode")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 arch/um/kernel/skas/syscall.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c
index bc117733e8ef..914b90af42ed 100644
--- a/arch/um/kernel/skas/syscall.c
+++ b/arch/um/kernel/skas/syscall.c
@@ -35,12 +35,13 @@ void handle_syscall(struct uml_pt_regs *r)
 	/*
 	 * If no time passes, then sched_yield may not actually yield, causing
 	 * broken spinlock implementations in userspace (ASAN) to hang for long
-	 * periods of time.
+	 * periods of time. Advance the time-travel clock a bit so sched_yield()
+	 * in a loop (like ping does for small intervals) also works correctly.
 	 */
 	if ((time_travel_mode == TT_MODE_INFCPU ||
 	     time_travel_mode == TT_MODE_EXTERNAL) &&
 	    syscall == __NR_sched_yield)
-		tt_extra_sched_jiffies += 1;
+		time_travel_ndelay(1000);
 
 	if (syscall >= 0 && syscall < __NR_syscalls) {
 		unsigned long ret;
-- 
2.55.0