Am 19.09.2024 um 16:22 schrieb Benjamin Berg:
Could this also eliminate/address the busy-loop hack in timer_read in
time.c?
Hmm, I was considering changing the other hack in handle_syscall to
also use this approach.
But, I don't think the timer_read hack can be removed. In the case of
userspace reading the time, it should not see the difference of the
sched_clock. So even though the process would start use CPU time, the
realtime clock should not change and python would continue to busyloop.
the actual clock ticks.
Okay, I think you are right.
Nonetheless, my proposal would be anyway to shift the advance of the
realtime clock only into user space systemcalls and not every function
in the kernel, that reads the timer.
I made ages ago the mediocre proposal to check the syscall number here,
to detect "malicious" user space programs doing busy loops.
For "clean" semantics of a simulative execution of the kernel, it feels
erroneous to advance time even if this value is only read once.
In my experiments timer_read was called much more often than I
anticipated (e.g., filesystem code).
