On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> When the timetravel ext modus is used, accessing the timetravel event
> list can be interrupted by a message on the timetravel socket in the
> SIGIO signal handler. This interruption can potentially modify the event
> list, leading to race conditions that cause deadlocks in the timetravel
> protocol or disrupt the ordered nature of the list, triggering bugs.
>
> Previously, the normal irq-save function did not intentionally block the
> timetravel handlers. However, the additional (un)block_signals_hard
> functions do block them. Therefore, these functions have been added at
> the appropriate places to address the issue.
>
> It's worth noting that although the functions are named as blocking,
> they primarily defer the actual execution of the SIGIO handlers until
> the unblock call. If no signal was issued, this mainly results in a
> variable assignment and a memory barrier.
Ahh ... _now_ I'm starting to understand what you meant earlier wrt.
signals and blocking and it not doing anything ...
> local_irq_save(flags);
> + block_signals_hard();
> list_for_each_entry(tmp, &time_travel_events, list) {
Yeah, indeed, signals are interrupts and we process them at a lower
level, so here our abstraction of disabling interrupts is leaky because
the signal can still happen to modify the list due to the
time_travel_add_irq_event() ...
Note I also have a race fix for signals_blocked_pending somewhere...
Need to find time to flush out more of our patches.
But yeah, I guess this makes sense.
johannes
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
