| Message ID | 20231103-bb-timetravel-patches-v1-7-e2c68efcf664@uni-rostock.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Several Time Travel Mode Enhancements | expand |
On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote: > Allow the so called Calendar (or simulation master) to request the > latest timetravel event. This can be used in situations, where the > former request message from UML to Calendar was missed. How ... is it possible to _miss_ a message?! It must've even sent an ACK to it...? johannes
Am 06.11.2023 um 21:33 schrieb Johannes Berg: > ________________________________ > > On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote: >> Allow the so called Calendar (or simulation master) to request the >> latest timetravel event. This can be used in situations, where the >> former request message from UML to Calendar was missed. > How ... is it possible to _miss_ a message?! It must've even sent an ACK > to it...? I must admit, this patch is older than those for protecting the event list. I think mostly I mean here, the UM-instance miss to send the current request, not that the calendar missed it :-) We were able to trigger that situation often, so I made some call to make a check what the current state in the instance is. Benjamin
On Fri, 2023-11-10 at 17:23 +0100, Benjamin Beichler wrote: > Am 06.11.2023 um 21:33 schrieb Johannes Berg: > > ________________________________ > > > > On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote: > > > Allow the so called Calendar (or simulation master) to request the > > > latest timetravel event. This can be used in situations, where the > > > former request message from UML to Calendar was missed. > > How ... is it possible to _miss_ a message?! It must've even sent an ACK > > to it...? > I must admit, this patch is older than those for protecting the event > list. I think mostly I mean here, the UM-instance miss to send the > current request, not that the calendar missed it :-) Oh. I think we should rather fix that bug though. I don't think we've observed it. I'm not entirely opposed to this, but relying on it for correctness seems wrong. Also, I've referred to it before, but with the shared memory the whole thing kind of goes away anyway since we just write the (earliest) request into the shared memory. Maybe if not many kids come singing tonight I'll try to send out some more patches ;) johannes
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c index 54fc4a69cb59..e513256eadfe 100644 --- a/arch/um/kernel/time.c +++ b/arch/um/kernel/time.c @@ -41,6 +41,7 @@ static bool time_travel_ext_prev_request_valid; static unsigned long long time_travel_ext_prev_request; static bool time_travel_ext_free_until_valid; static unsigned long long time_travel_ext_free_until; +static struct time_travel_event *time_travel_first_event(void); static void time_travel_set_time(unsigned long long ns) { @@ -66,6 +67,7 @@ static void time_travel_handle_message(struct um_timetravel_msg *msg, .op = UM_TIMETRAVEL_ACK, }; int ret; + struct time_travel_event *event; /* * We can't unlock here, but interrupt signals with a timetravel_handler @@ -103,6 +105,10 @@ static void time_travel_handle_message(struct um_timetravel_msg *msg, time_travel_ext_free_until_valid = true; time_travel_ext_free_until = msg->time; break; + case UM_TIMETRAVEL_REQUEST: + event = time_travel_first_event(); + resp.time = event->time; + break; } resp.seq = msg->seq;
Allow the so called Calendar (or simulation master) to request the latest timetravel event. This can be used in situations, where the former request message from UML to Calendar was missed. Signed-off-by: Benjamin Beichler <benjamin.beichler@uni-rostock.de> --- arch/um/kernel/time.c | 6 ++++++ 1 file changed, 6 insertions(+)