[PATCH 1/4] um: irqs: process outstanding IRQs when unblocking signals

[Benjamin Beichler]

Am 18.10.2023 um 14:36 schrieb benjamin at sipsolutions.net:
> From: Benjamin Berg <benjamin.berg at intel.com>
> 
> When in time-travel mode, the eventfd events are read even when signals
> are blocked as SIGIO still needs to be processed. In this case, the
> event is cleared on the eventfd but the IRQ still needs to be fired
> later.
> 
> We did already ensure that the SIGIO handler is run again. However, the
> FDs are configured to be level triggered, so that eventfd will not
> notify again. As such, add some logic to mark the IRQ as pending and
> process it at the next opportunity.
> 
> To avoid duplication, reuse the logic used for the suspend/resume case.
> This does not really change anything except for delaying running the
> IRQs with timetravel_handler at a slightly later point in time (and
> possibly running non-timetravel IRQs that shouldn't happen earlier).
> While at it, move marking as pending into irq_event_handler as that is
> the more logical place for it to happen.
> 
> Signed-off-by: Benjamin Berg <benjamin.berg at intel.com>

I also noticed this problem, but after a discussion with Johannes Berg 
about this, we come to the conclusion, that all drivers with interrupts 
need to deal with time travel mode via their own time travel handler. 
What I actually did, was to write a trivial handler for e.g., the serial 
line, which simply only call time_travel_add_irq_event(ev).

I'm not entirely sure, what the right way to do it, although the outcome 
seems to be the same, as with no time advance the actual simulation 
time, when the interrupt is handled is the same.

I actually also have some other significant bug fixes on time travel in 
my tree, but I was too lazy to send them here, are you interested in 
taking a look at them?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1569BBF90AC3918A.asc
Type: application/pgp-keys
Size: 2976 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/linux-um/attachments/20231020/c3cc64bc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-um/attachments/20231020/c3cc64bc/attachment.sig>