Container Sandbox: Unsupported syscall UNKNOWN[439/0x1b7](0xffffffffffffff9c,0x3e080c92c500,0x1,0x200,0x200,0x3e080c92c500).
steren opened this issue · comments
Description
In Cloud Run first generation execution environment, which uses gVisor, I get this debug log:
Container Sandbox: Unsupported syscall UNKNOWN[439/0x1b7](0xffffffffffffff9c,0x3e080c92c500,0x1,0x200,0x200,0x3e080c92c500).
I am running this code
Steps to reproduce
No response
runsc version
No response
docker version (if using docker)
No response
uname
No response
kubectl (if using Kubernetes)
No response
repo state (if built from source)
No response
runsc debug logs (if available)
No response
Per the x86_64 syscall table, this is a call to faccessat2. Because the syscall is relatively new, most likely the code is attempting to use it, then falling back to another syscall (probably faccessat). It probably doesn't affect the correctness of the code -- this is a common way for applications to test whether they can use the newest features that exist only in the newest kernels.
Is this affecting correctness (i.e. causing an error), or just producing a log line?
It doesn't seem to affect production. I would suggest to silence if after an analysis we confirm we expect software to fallback to other syscalls (which you did)
gVisor probably won't want to silence this. Some things we do silence, e.g. 007a91a. That commit can safely be silenced because use of SO_RCVLOWAT doesn't affect correctness.
But it's possible for some app or library to be written without a fallback. In those cases, we don't want to silence the warning.
It seems that faccessat2 is pretty easily implementable. Can we just knock that out? It is only faccess with the ability to specify whether symlinks should be followed and whether effective UID/GIDs should be used. See also:
https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/syscalls/linux/sys_file.go;drc=5c95e1d39c19a9783a919783cbf65534d30437d6;l=575
https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/syscalls/linux/sys_file.go;drc=3b83c30622c043d57a393b26018ad6a41b924684;l=535
faccessat2 is already implemented in VFS2:
https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/vfs2/vfs2.go#L166
VFS2 is enabled by default in almost all environments, but is still rolling out to Cloud Run. Hopefully that rollout will finish soon.