1 files changed, 13 insertions, 14 deletions

diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 1003a4d5eb25..2c00a691a540 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -1041,6 +1041,8 @@ static int trace_wakeup_test_thread(void *data)
         set_current_state(TASK_INTERRUPTIBLE);
         schedule();
 
+        complete(x);
+
         /* we are awake, now wait to disappear */
         while (!kthread_should_stop()) {
                 /*
@@ -1084,24 +1086,21 @@ trace_selftest_startup_wakeup(struct tracer *trace, struct trace_array *tr)
         /* reset the max latency */
         tracing_max_latency = 0;
 
-        /* sleep to let the RT thread sleep too */
-        msleep(100);
+        while (p->on_rq) {
+                /*
+                 * Sleep to make sure the RT thread is asleep too.
+                 * On virtual machines we can't rely on timings,
+                 * but we want to make sure this test still works.
+                 */
+                msleep(100);
+        }
 
-        /*
-         * Yes this is slightly racy. It is possible that for some
-         * strange reason that the RT thread we created, did not
-         * call schedule for 100ms after doing the completion,
-         * and we do a wakeup on a task that already is awake.
-         * But that is extremely unlikely, and the worst thing that
-         * happens in such a case, is that we disable tracing.
-         * Honestly, if this race does happen something is horrible
-         * wrong with the system.
-         */
+        init_completion(&isrt);
 
         wake_up_process(p);
 
-        /* give a little time to let the thread wake up */
-        msleep(100);
+        /* Wait for the task to wake up */
+        wait_for_completion(&isrt);
 
         /* stop the tracing. */
         tracing_stop();