Make ozone/drm/mojo more immune to startup races

ui/ozone/platform/drm/ozone_platform_gbm.cc

Index: ui/ozone/platform/drm/ozone_platform_gbm.cc
diff --git a/ui/ozone/platform/drm/ozone_platform_gbm.cc b/ui/ozone/platform/drm/ozone_platform_gbm.cc
index df0cb0a2d8b04471226174852b8a0d78d91cb5bb..b8a623a41c4a565c1f5a0d814d8181c018ea96c0 100644
--- a/ui/ozone/platform/drm/ozone_platform_gbm.cc
+++ b/ui/ozone/platform/drm/ozone_platform_gbm.cc
@@ -124,8 +124,6 @@ class OzonePlatformGbm : public OzonePlatform {
       const gfx::Rect& bounds) override {
     GpuThreadAdapter* adapter = gpu_platform_support_host_.get();
     if (using_mojo_ || single_process_) {
-      DCHECK(drm_thread_proxy_)
-          << "drm_thread_proxy_ should exist (and be running) here.";
       adapter = mus_thread_proxy_.get();
     }
 
@@ -179,7 +177,9 @@ class OzonePlatformGbm : public OzonePlatform {
       DCHECK(args.connector);
       mus_thread_proxy_.reset(new MusThreadProxy());
       adapter = mus_thread_proxy_.get();
-      cursor_->SetDrmCursorProxy(new CursorProxyMojo(args.connector));
+      auto cursor_proxy = new CursorProxyMojo(args.connector);
+      mus_thread_proxy_->AddGpuThreadObserver(cursor_proxy);

[kylechar, 2017/05/30 19:46:22]

I think this will result in a use after free?

|cursor_| and the CursorProxyMojo it owns will be destroyed before
|mus_thread_proxy_| is destroyed. When MusThreadProxy is destroyed it will
notify all of the observers that are still registered including CursorProxy.

[dnicoara, 2017/05/30 20:35:17]

On the old path the cursor is special cased and notified last otherwise window
creation events (scheduled off the UI thread) may race with cursor input events
(scheduled off the event thread). Wouldn't this be the case in MUS as well?

[rjkroege, 2017/05/31 00:39:14]

Done.

[rjkroege, 2017/05/31 00:39:14]

I don't understand. The creation of the CursorProxyMojo can safely happen here.
And the cursor is still special cased (see pending_cursor_requests_).

[dnicoara, 2017/05/31 15:01:14]

Cursor creation is fine. I'm referring to the order in which the
GpuThreadObservers are called. Perhaps I'm misunderstanding what the mojo
binding is doing, but this is the case I'm thinking of:

1. mus_thread_proxy_->AddGpuThreadObserver(cursor_proxy)
2. CreatePlatformWindow(...)
3. mus_thread_proxy_->StartDrmThread() // This calls the observers
  a. cursor_proxy->OnGpuThreadReady()
  b. DrmWindowHost::OnGpuThreadReady() // This is the window created in step 2

The cursor_proxy may start sending cursor events before the window is created on
the GPU side since it has been notified first. So DrmThread::MoveCursor() may be
called before DrmThread::CreateWindow().

If (a) is the last notification, then the above case would never happen since
DrmWindowHost::OnGpuThreadReady() would queue the window creation message before
cursor_proxy is notified of GPU startup.

+      cursor_->SetDrmCursorProxy(cursor_proxy);

[kylechar, 2017/05/30 19:46:22]

Can this be changed to take a unqiue_ptr?

[rjkroege, 2017/05/31 00:39:14]

Done.

     } else if (single_process_) {
       mus_thread_proxy_.reset(new MusThreadProxy());
       adapter = mus_thread_proxy_.get();