Draft: sys/ztimer: guard against spurious ISR

[Enoch247]

Contribution description

This patch changes ztimer_handler() to properly deal with spurious ISRs. Without the patch, a spurious ISR will potentially cause mutliple timers to fire early. With this patch, these ISRs are properly ignored.

The downside of this PR is that it increases the overhead of the ztimer ISR execution. One option would be to only enable it when DEVELHELP is set. Another option is to make this the default behavior, but revert to the old behavior for MCU's where the periph_timer is well tested and known the never cause spurious ISRs. This would ease porting of new MCUs where the timer driver may not be as mature yet.

Testing procedure

Testing procedure is the same as #20924.

Issues/PRs references

• This PR can be used instead of, or together with sys/ztimer: fix re-scheduling of timers #20924.
• cpu/stm32/periph/timer: prevent spurious IRQs #20926 is a good example of how an implementation of periph_timer could lead to spurious ISRs, and it is only one implementation. It is likely that such errors could exist in other drivers.

[Enoch247]

I am marking this as draft because of the potential performance impact. I need to quantify it. If it is not small, this feature should be made optional. I have had some hints in using this code that the performance impact may not be acceptable as a general solution to all users.

[benpicco]

What is a spurious IRQ and why would they occur?
Sounds more like a bug in the timer driver, not something we should work around in an upper layer, because that will bite every hw timer user, not just ztimer.

[Enoch247]

Spurious IRQs are jumps into the ISR that are unwanted/unexpected. A bug could be a likely cause, but the term can also be applied (as I understand it) in situations that arrive due to sequential code interacting with parallel hardware.

I made this change to work around spurious IRQs into ztimer that I was seeing. I later figured out the root cause and fixed that in PR #20924. In that same investigation, I discovered that there was another possible source of spurious ISRs and that proposed fix is in #20926.

I am fine with dropping this PR outright, or making it a pseudomodule, since it is a workaround. I think @maribu was in favor of the change, so may want to give him a chance to speak up before closing it.