The driver for a whatever reason opens /, then duplicates this fd and closes both. At least, the driver shouldn’t do that. (because, for example, it’s probably a performance bottleneck)
It breaks applications that isolate themselves, for example if an application (like rvvm) isolates itself with a seccomp filter that returns -EPERM for useless system calls (like open/at), then those system calls will fail with this error. And if the nvidia driver can’t open /, it will silently crash.
^^^ This is about OpenGL.
Also, with vulkan, the driver tries to open /dev/nvidiactl (or/and /dev/nvidia0?) every frame. But unlike OpenGL, it does not crash if it fails to open.
This is part of a workaround where the driver needs to dup a file descriptor and set the O_CLOEXEC flag at the same time. It does this by opening a dummy file descriptor with O_CLOEXEC and then using dup3() to dup the actual file descriptor on top of it with O_CLOEXEC already set. Otherwise, there’s a race where the application can call exec() between when the original file descriptor is dup()'d and the driver can call fcntl(fd, F_SETFD, ... | FD_CLOEXEC) on it to prevent it from being inherited by the executed program.
Yes, you’re right. I verified that all of our supported platforms support it now and switched to that in our mainline branch, although that won’t show up in a release for a while. I would not expect to see any performance improvement though.
