ozone gpu, specifically, the drm implementation, is racy.

ui::GpuPlatformSupportHost recently had a change [1] that made it used from both the IO and the UI thread. The way this currently works:

a. [IO] GpuProcessHost is created. It posts a task to the UI thread to create a GpuProcessHostUIShim. It also immediately calls GpuPlatformSupportHost::OnGpuProcessLaunched(). This triggers OnGpuProcessLaunched() on the list of GpuThreadObservers in DrmGpuPlatformSupportHost.

b. [UI] The task posted in step a. runs, and the GpuProcessHostUIShim is created. Upon creation, it calls GpuPlatformSupportHost::OnChannelEstablished(). This triggers OnGpuThreadReady() on the observers in DrmGpuPlatformSupportHost.

There are two issues here:

1. The task can run on UI thread before the task on the IO thread completes. That means OnGpuThreadReady() can run before OnGpuProcessLaunched() on the observers.
2. The list of observers in DrmGpuPlatformSupportHost (and some other states, e.g. |host_id_|) are accessed from both the UI and the IO threads without using any locks.
3. Consequently, DrmDisplayHostManager (which is-a GpuThreadObserver) also uses reads+mutates |drm_devices_| on both threads, without using locks. (e.g. [2], [3], [4]).

https://codereview.chromium.org/2820463002/ helps with 1, ensuring that the calls on the observers happen in a well defined order.
Using a ObserverListThreadSafe<> (instead of ObserverList<>) may be an option to help with 2, but maybe a lock would be better?

[1] https://codereview.chromium.org/2459973002/
[2] UI thread: https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/host/drm_display_host_manager.cc?type=cs&sq=package:chromium&l=276
[3] UI thread: https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/host/drm_display_host_manager.cc?type=cs&sq=package:chromium&l=288
[4] IO thread: https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/host/drm_display_host_manager.cc?type=cs&sq=package:chromium&l=318