> The accumulation of i915_request implies there is a fence leak. Assuming it is not internal (an unmatched dma_fence_get/dma_fence_put), all userspace owners would be tied to an fd and eventually one would notice the fd exhaustion (after a few million depending on rlimit).
It is not tied to a file descriptor because I915_EXEC_FENCE_OUT is not set in args->flags (that was worked out by working backward from a perf trace). This means that DEFINE_DRM_GEM_FOPS->drm_release is never called, and we never get dma_fence_put() from this (hypothetical) stack:
Also, my system is also affected by this. I have a Xeon E3-1276v3. I am running Gentoo with Linux 4.18.0-rc8, Xorg 1.19.5, mesa 18.1.6 and vulkan-loader 1.1.77.0. I have killed the Xorg server and the i915_request objects were not freed from the SLAB cache. This implies that the objects are not tied to a file descriptor.
> The accumulation of i915_request implies there is a fence leak. Assuming it is not internal (an unmatched dma_fence_ get/dma_ fence_put) , all userspace owners would be tied to an fd and eventually one would notice the fd exhaustion (after a few million depending on rlimit).
It is not tied to a file descriptor because I915_EXEC_FENCE_OUT is not set in args->flags (that was worked out by working backward from a perf trace). This means that DEFINE_ DRM_GEM_ FOPS->drm_ release is never called, and we never get dma_fence_put() from this (hypothetical) stack:
dma_fence_put release_ handle
drm_syncobj_free
kref_put
drm_syncobj_put
drm_syncobj_
drm_syncobj_release
drm_release
The trace at github indirectly shows that out_fence_fd == -1:
https:/ /github. com/doitsujin/ dxvk/issues/ 632#issuecommen t-420485691
Also, my system is also affected by this. I have a Xeon E3-1276v3. I am running Gentoo with Linux 4.18.0-rc8, Xorg 1.19.5, mesa 18.1.6 and vulkan-loader 1.1.77.0. I have killed the Xorg server and the i915_request objects were not freed from the SLAB cache. This implies that the objects are not tied to a file descriptor.