Repository navigation
Don't close the fd again after a failed cuImportExternalMemory - #479
Merged
elFarto merged 1 commit intoOct 11, 2026
Merged
Conversation
libcuda takes ownership of the OPAQUE_FD handle passed to cuImportExternalMemory and closes it even when the import fails (observed with 615.71.09, verified with an LD_PRELOAD close() tracer). The driver then closed the same descriptor a second time in every failure path. In a single-threaded caller that only yields EBADF, but in a multi-threaded process such as Chromium's GPU process another thread can allocate the same number in between, and the second close() silently destroys that thread's descriptor. Chromium later hits the PCHECK in base/files/scoped_file.cc when it closes the dma-buf fd of a video frame, and the GPU process dies with SIGTRAP (exit code 133). The failing import is reached whenever Chromium's VaapiImageProcessor re-imports frame-pool dma-bufs through a second VADisplay: the second NVDriver instance has no backing-image cache hit, mmap() of the dma-buf fails with EACCES and cuImportExternalMemory returns CUDA_ERROR_UNKNOWN. Never touch the descriptor after cuImportExternalMemory, regardless of the result: importExternalBackingToCuda, importExternalBufferToCuda, direct_allocateBackingImage_perPlane/_single and import_to_cuda. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Owner
|
This is a good catch, thanks for the patch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #478.
libcuda (615.71.09) takes ownership of the
CU_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FDdescriptor passed tocuImportExternalMemory()and closes it even when the import fails. The driver then closed the same descriptor a second time in every failure path:importExternalBackingToCuda()/importExternalBufferToCuda():close(importFd)direct_allocateBackingImage_perPlane():close(memFd)direct_allocateBackingImage_single():fail:closesmemFdimport_to_cuda(): returns withimage->nvFdstill set, sobail:closes it againIn a multi-threaded client another thread can allocate the same descriptor number between the two closes, and the second
close()destroys that thread's fd. This is how Chromium's GPU process ends up withFATAL:base/files/scoped_file.cc:45 Check failed: . : Bad file descriptor (9)(SIGTRAP,exit_code=133) some seconds after a batch ofvaCreateSurfaces (import mode) failed, VA error: resource allocation failedfrom its VaapiImageProcessor. Details, logs and a browser-free reproduction are in #478.The change never touches the descriptor after
cuImportExternalMemory(), regardless of the result. Success paths are unchanged.Tested on master
d03f8cb, RTX 4070, driver 615.71.09,NVD_BACKEND=direct, with the reproduction from #478 under aclose()tracer:close()with EBADF per failed importVA_STATUS_ERROR_ALLOCATION_FAILEDVA_STATUS_ERROR_ALLOCATION_FAILED(unchanged, as expected)H.264 / VP9 / AV1 decoding and dma-buf export in Chromium 153 keep working with the patched driver.
🤖 Generated with Claude Code