The number of UM_TIMETRAVEL_REQUEST msgs is tried to reduced, if they
are redundant via the time_travel_ext_prev_request_valid flag. This can
create a race condition, when an interrupt happens and the idle loop
wants to wait.
This means, sometimes the UM_TIMETRAVEL_REQUEST are sent(when the idle
loop already started waiting) and sometimes not, which makes it harder
to implement the other end of the scheduler. Therefore, this fix make
the time travel protocol a bit more deterministic by always sending the
UM_TIMETRAVEL_REQUEST msg.
Signed-off-by: Benjamin Beichler <benjamin.beich...@uni-rostock.de>
---
arch/um/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index abd5fd0f62ee..54fc4a69cb59 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -446,6 +446,7 @@ void time_travel_add_irq_event(struct time_travel_event *e)
BUG_ON(time_travel_mode != TT_MODE_EXTERNAL);
time_travel_ext_get_time();
+ time_travel_ext_prev_request_valid = false;
/*
* We could model interrupt latency here, for now just
* don't have any latency at all and request the exact
--
2.34.1
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
