Hi, On Thu, 2024-09-19 at 16:37 +0200, Benjamin Beichler wrote: > 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.
And now here I am proposing another form of "malicious" userspace detection … > 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). Yeah, that does not really sound like something we would want (and it will also not help with performance with time-travel=ext). Looking at the old discussion, it doesn't seem that Johannes was against the idea of doing the time insertion only in more specific scenarios. So, we "just" need a reasonably elegant solution. If we accept writing a list of syscalls, then maybe we could just do it within handle_syscall and do a um_udelay(1) for any syscall that takes a timeout parameter (select, pselect6, poll, ...)? It is going to be a pretty long list, but could still be reasonable. One neat side effect is that if reading time does not actually cost time, then we could implement clock_gettime in the VDSO. Benjamin
