[PATCH RFC 10/11] um: Delay timer_read only in possible busy loops in TT-mode

[Johannes Berg]

On Fri, 2023-11-03 at 16:41 +0000, Benjamin Beichler wrote:
> This slows down external TT-mode as more simulation roundtrips are
> required, and it unnecessarily affects the determinism and accuracy of
> the simulation.

I still don't think this is really true, it doesn't really affect
determinism? It makes it ... different, sure, but not non-deterministic?



> +static const int suspicious_busy_loop_syscalls[] = {
> +	36, //sys_getitimer
> +	96, //sys_gettimeofday
> +	201, //sys_time
> +	224, //sys_timer_gettime
> +	228, //sys_clock_gettime
> +	287, //sys_timerfd_gettime
> +};

That's kind of awful. Surely we can use __NR_timer_gettime etc. here at
least?

> +static bool suspicious_busy_loop(void)
> +{
> +	int i;
> +	int syscall = syscall_get_nr(current, task_pt_regs(current));
> +
> +	for (i = 0; i < ARRAY_SIZE(suspicious_busy_loop_syscalls); i++) {
> +		if (suspicious_busy_loop_syscalls[i] == syscall)
> +			return true;
> +	}

Might also be faster to have a bitmap? But ... also kind of awkward I
guess.

I dunno. I'm not even sure what you're trying to achieve - apart from
"determinism" which seems odd or even wrong, and speed, which is
probably easier done with a better free-until and the shared memory
calendar we have been working on.

johannes