Vulkan external fd handling when OS revokes file descriptors

Direct answers

Validation layer diagnostics: No. Validation layers validate Vulkan API usage, not kernel object lifetimes. Once an external fd has been imported into a VkDeviceMemory or VkSemaphore, the layer cannot track whether the underlying descriptor is later closed or revoked, so it will not warn when a submitted command buffer references a stale handle.

Duplicating with FD_CLOEXEC and closing the original: No. The specification does not require the implementation to duplicate the fd at import time. A conformant driver may retain the original fd number for later waits, mapping, or submission operations. Closing the original after duplication is therefore not portable and may cause undefined behavior, VK_ERROR_INVALID_EXTERNAL_HANDLE, or silent corruption.

Guaranteed synchronization point: No. Queue submission, fence signaling, and semaphore waits do not provide a portable guarantee that the driver has finished consuming the descriptor. There is no Vulkan query or callback that reports fd consumption.

Why the gap exists

The Vulkan specification explicitly leaves behavior implementation-defined when an imported external handle becomes invalid after the application closes it or the OS revokes it. From the driver's perspective, an application close and an OS-level revocation (for example, FD_CLOEXEC on exec or container teardown) are indistinguishable. Because drivers may defer descriptor use until submission or mapping, the API cannot expose a safe early-close point without breaking that flexibility.

Portable pattern

The only portable rule is to retain the original fd for the entire lifetime of the imported Vulkan object:

1. Keep the fd open from import until the corresponding vkFreeMemory or vkDestroySemaphore call completes.
2. Close the fd only after the destroy call returns.
3. If least-privilege fd management is required, enforce the boundary at the process or namespace level rather than by closing the descriptor early.

Verification on a specific driver

Because the specification does not mandate a duplication strategy, you can verify your driver's behavior experimentally:

• Enable validation layers and submit command buffers that reference imported memory or semaphores after closing the original fd. Confirm whether any warnings appear on your target driver.
• Use strace or driver debug logs to observe whether the implementation issues dup, ioctl, or close on the imported fd during import and subsequent queue operations.
• Check vendor documentation or release notes for an explicit statement that imported fds are duplicated at import time. If no such statement exists, assume the original fd must remain open.

These checks are diagnostic only; they do not create a portable guarantee across other conformant drivers.