Bug 237758 - [Linux] GBMDevice as a thread-specific object is problematic
Summary: [Linux] GBMDevice as a thread-specific object is problematic
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Zan Dobersek
Keywords: InRadar
Depends on:
Blocks: DMA-BUF
  Show dependency treegraph
Reported: 2022-03-11 00:38 PST by Zan Dobersek
Modified: 2022-03-18 06:31 PDT (History)
8 users (show)

See Also:

Patch (7.05 KB, patch)
2022-03-18 03:28 PDT, Zan Dobersek
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2022-03-11 00:38:45 PST
GBMDevice, and the gbm_device instance it wraps, can cause problems when managed on a thread-specific basis. gbm_bo objects created through these devices can be shipped or used across different threads, but it can also happen that the thread on which they were created through the GBMDevice/gbm_device specific to that thread is destroyed while gbm_bo objects live on. So the gbm_device is destroyed but the gbm_bo objects created through it live on, causing problems when the gbm_bo instance tries to use now-destroyed gbm_device for different operations.

This is happening under certain circumstances inside GStreamer integration along with the swapchain object (bug #237238). Swapchain remains the same for the duration of the MediaPlayerPrivateGStreamer's lifetime. During the first playback, GStreamer's pipeline handles playback on one thread, spawning gbm_bo objects as required given that thread's GBMDevice. Once playback finishes, the pipeline will deconstruct these threads and the GBMDevice, which leaves the swapchain objects with a dangling gbm_device pointer.

Mesa's libgbm is a useful wrapper along the specified DRI device file descriptor. I don't see possible thread-safety issues there, or at least have not experienced them so far working with that library. There's other implementations (closed-source too) that might not be so generous, but I would presume thread safety first. If things go sideways there's options of having a libgbm-specific thread where these allocations are performed, but the basis even before that would be a single per-process gbm_device.
Comment 1 Radar WebKit Bug Importer 2022-03-18 01:39:18 PDT
Comment 2 Zan Dobersek 2022-03-18 03:28:13 PDT
Created attachment 455083 [details]
Comment 3 Alejandro G. Castro 2022-03-18 03:33:44 PDT
Comment on attachment 455083 [details]

Comment 4 EWS 2022-03-18 06:31:40 PDT
Committed r291480 (248594@main): <https://commits.webkit.org/248594@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 455083 [details].