Our seccomp filter currently always passes through the sched_yield syscall to avoid recursing in the shim's own spin lock.
If we don't intercept sched_yield via LD_PRELOAD, e.g. because use_preload_libc is false or because the managed code makes a direct syscall, this causes us to execute the syscall natively instead of emulating it. In some cases this is ok, but it breaks our ability to escape busy loops using model_unblocked_syscall_latency.
Removing the sched_yield exception in our seccomp filter, in shim_seccomp_init, seemed to work OK for me locally, but I wouldn't be surprised if there was a race condition s.t. it caused occasional failures in practice.
The right fix is probably to add a better mechanism for shadow_spinlock to ensure its sched_yield executes natively.
Our seccomp filter currently always passes through the
sched_yieldsyscall to avoid recursing in the shim's own spin lock.If we don't intercept
sched_yieldvia LD_PRELOAD, e.g. becauseuse_preload_libcis false or because the managed code makes a direct syscall, this causes us to execute the syscall natively instead of emulating it. In some cases this is ok, but it breaks our ability to escape busy loops usingmodel_unblocked_syscall_latency.Removing the sched_yield exception in our seccomp filter, in
shim_seccomp_init, seemed to work OK for me locally, but I wouldn't be surprised if there was a race condition s.t. it caused occasional failures in practice.The right fix is probably to add a better mechanism for
shadow_spinlockto ensure itssched_yieldexecutes natively.