Deferred notify and IRQ ack may be overwritten

[dreamliner787-9]

It is possible for the user to call the deferred APIs microkit_deferred_notify() and microkit_deferred_irq_ack() multiple time before returning to the event loop for the deferred action to be serviced. Since the deferred APIs just set global variables then return control to user code, this will cause the earlier deferred action to be overwritten by the latest one.

To fix this, an idea from @midnightveil is that in the deferred API, we can check whether a event is already pending, if so then send the signal / IRQ ack then queue up the next action.

[midnightveil]

To fix this, an idea from @midnightveil is that in the deferred API, we can check whether a event is already pending, if so then send the signal / IRQ ack then queue up the next action.

That's not my preferred solution (nor was it my idea), but it would "work". I'd prefer that these be reworked entirely.

[Indanz]

The docs say "It is important to note that only a single ‘deferred’ API call can be made within the same entry point.", so it seems just a user bug.

That said, should be easy to detect and avoid though, in which case you can as well do it in the normal microkit_notify and hide this optimisation altogether. In the grand scheme of things, I'm not sure if saving one syscall is worth the extra burden it brings to your event loop handling and the need of wrapper functions, compared to letting the user call the seL4 API directly.

[midnightveil]

Related: au-ts/sddf#76