Ran into a situation where a child process using drmModeAtomicCommit() terminates unexpectedly but its most recently displayed framebuffer remains visible if the parent process is also using drmModeAtomicCommit(). If the parent process uses drmModePageFlip(), then the child framebuffer is removed as expected. Presumably if a subsequent process allocated memory overlapping the old framebuffer (which comes from either "/dev/dma_heap/system" or "/dev/dma_heap/linux,cma"), that data would be visualized by the HVS until some process resets the display list. Have run into this issue on both Pi4 & Pi5 under bookworm.

Question-- Is VC4 supposed to recognize a framebuffer has been freed and remove it from the display-list?

Last edited by Vraz on Thu Jan 23, 2025 3:18 pm, edited 1 time in total.

Some additional detail-- the parent process is a UI layer using WPEWebKit rendering via EGL+drmModeAtomicCommit. For media playback, it fork+execs a child process and passes its open libdrm file descriptor. The child media player process displays its own media playback plane and OSD UI plane. If the player terminates abnormally, those planes remain visible. When the WPEWebKit renders its next frame, it remains obscured "under" the now orphaned media player planes. Worked around the issue by making the media player fork and then wait for itself to terminate allow reliable cleanup regardless of how the player terminated.

Since the orphaned framebuffer was allocated via "/dev/dma_heap/system" by the now terminated media player, had assumed that memory could be inadvertantly reallocated. However, running memory stress tests never changed the display. Does calling DRM_IOCTL_PRIME_FD_TO_HANDLE with the shared libdrm file descriptor mean the framebuffer lifespan is partially tied to the libdrm file descriptor lifespan (when shared between multiple processes)?

DRM cleans up and restores the framebuffer on the closing of the last file handle for the /dev/dri/cardN device. If you're keeping it open for the UI process (and presumably have passed it across to the player process) then that doesn't apply, so there is no cleanup.

Yes calling DRM_IOCTL_PRIME_FD_TO_HANDLE increases the refcount on the underlying allocation, and will hold it until all refcount are released.

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Thanks for the clarification-- makes sense. One minor oddity-- when a child enumerates the planes, it will get back the fb_id for any planes the parent displayed. While the child can hide/replace that plane with one of its own, it cannot restore the parents plane using that fb_id. Don't recall if it returned an error or was simply ignored. That process-specific aspect puzzled me a bit.

Security.
If you were allowed to restore any FB_ID, then you could sit there and try each value sequentially and spy on all other graphics resources in the system. If you were allowed to add that to a writeback connector, then you could take a copy of that frame too.
Giving you the FB_ID that's currently on the plane shouldn't give you any extra information that you shouldn't have.

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.