Vulkan external fd handling when OS revokes file descriptors
0 reputation · 06 May 2022, 05:09 UTC
Context
Vulkan allows importing external memory and semaphores via OS file descriptors through VK_EXT_external_memory_fd and VK_EXT_external_semaphore_fd. The specification states that behavior is implementation-defined when an imported handle becomes invalid after the application closes it or the OS revokes it.
Constraint
Applications must maintain valid descriptors until Vulkan no longer references them, but no Vulkan query or callback exists to detect revocation. Drivers may return VK_ERROR_INVALID_EXTERNAL_HANDLE, produce undefined behavior, or silently corrupt submissions. This creates a gap between least-privilege fd management (closing descriptors early) and safe Vulkan usage.
Goal
Determine whether a portable pattern exists for detecting or preventing use-after-revoke without relying on vendor-specific behavior.
Does the validation layer surface any diagnostic when a submitted command buffer references a stale fd? Can an application safely duplicate the descriptor with FD_CLOEXEC and close the original without triggering undefined behavior across all conformant drivers? Is there a recommended synchronization point where the driver guarantees it has consumed the fd so the application may close it?
