gfx: Struct traits for GpuMemoryBufferHandle.

gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change

Committed: https://crrev.com/5569cc1d0d05edce033dc92096ad5d5b03067907
Cr-Commit-Position: refs/heads/master@{#416362}

[sadrul, 2016-08-31 00:50:53]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 00:51:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 00:54:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 00:54:34]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sadrul, 2016-08-31 02:01:47]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 02:02:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 02:33:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 02:33:01]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[sadrul, 2016-08-31 03:10:20]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 03:10:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 03:24:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 03:24:37]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[sadrul, 2016-08-31 04:27:30]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 04:27:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 04:40:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 04:40:20]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sadrul, 2016-08-31 04:42:05]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 04:42:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 05:16:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 05:16:02]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sadrul, 2016-08-31 05:48:22]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 05:48:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 06:23:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 06:23:21]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sadrul, 2016-08-31 07:19:16]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 07:19:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sadrul, 2016-08-31 07:30:19]

Description was changed from

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed.

BUG=637923
==========

to

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
==========

[sadrul, 2016-08-31 07:31:41]

sadrul@chromium.org changed reviewers:
+ rjkroege@chromium.org, tsepez@chromium.org

[sadrul, 2016-08-31 07:31:42]

rjkroege@ for native_pixmap_handle_ozone.cc => native_pixmap_handle.cc change.

tsepez@ for the mojoms, typemaps, and struct-traits.

[commit-bot: I haz the power, 2016-08-31 08:28:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 08:28:43]

Dry run: This issue passed the CQ dry run.

[Tom Sepez, 2016-08-31 16:52:36]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/gfx.gyp
File ui/gfx/gfx.gyp (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/gfx.gyp#newcode103
ui/gfx/gfx.gyp:103: "win/physical_size.cc",
nit: alphabetize.

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:55: int32 stride;
Can these be negative?  Would an unsigned type be more appropriate? Otherwise we
have to check for < 0 in a lot of places, no?

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:74: int32 stride;
nit: same here.

[Tom Sepez, 2016-08-31 17:04:15]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:65: array<NativePixmapPlane> planes;
Anyways, where do we check upon de-serialization that the combination of strides
and offsets etc. doesn't overflow the bounds of the underlying memory?

[Fady Samuel, 2016-08-31 17:06:01]

fsamuel@chromium.org changed reviewers:
+ fsamuel@chromium.org

[Fady Samuel, 2016-08-31 17:06:02]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types_traits.cc (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types_traits.cc:31: if (!data.ReadFds(&handles))
GetFdsDataView and iterate directly inside the buffer instead of deserializing
everything in on vector and then copying again?

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types_traits.h (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types_traits.h:230: static std::vector<mojo::ScopedHandle>
fds(
This will create a copy of the vector which may be expensive. If this vector is
usually small, could you please say so in a comment?

[sadrul, 2016-08-31 17:13:19]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/gfx.gyp
File ui/gfx/gfx.gyp (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/gfx.gyp#newcode103
ui/gfx/gfx.gyp:103: "win/physical_size.cc",
On 2016/08/31 16:52:36, Tom Sepez wrote:
> nit: alphabetize.

Done (I have no idea how these moved up here)

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:65: array<NativePixmapPlane> planes;
On 2016/08/31 17:04:15, Tom Sepez wrote:
> Anyways, where do we check upon de-serialization that the combination of
strides
> and offsets etc. doesn't overflow the bounds of the underlying memory?

It doesn't look like we actually check that anywhere currently. The host (i.e.
chrome browser, or the window server) receives these from the gpu process, and
sends them off back to the clients (i.e. renderers) or processes them locally,
without doing any bounds checking.

[Tom Sepez, 2016-08-31 17:15:30]

> It doesn't look like we actually check that anywhere currently. The host (i.e.
> chrome browser, or the window server) receives these from the gpu process, and
> sends them off back to the clients (i.e. renderers) or processes them locally,
> without doing any bounds checking.

That doesn't sound good.  For the GPU -> Renderer, we're decreasing privilege,
so that would be OK. For the GPU -> browser, can you look into where we use
these as indicies?

[spang, 2016-08-31 19:35:56]

spang@chromium.org changed reviewers:
+ spang@chromium.org

[spang, 2016-08-31 19:35:57]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:55: int32 stride;
On 2016/08/31 16:52:36, Tom Sepez wrote:
> Can these be negative?  Would an unsigned type be more appropriate? Otherwise
we
> have to check for < 0 in a lot of places, no?

Please don't do that.

https://engdoc.corp.google.com/eng/doc/devguide/cpp/styleguide.shtml?cl=head#...

[sadrul, 2016-08-31 19:52:04]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 19:52:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sadrul, 2016-08-31 19:53:20]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:55: int32 stride;
On 2016/08/31 16:52:36, Tom Sepez wrote:
> Can these be negative?  Would an unsigned type be more appropriate? Otherwise
we
> have to check for < 0 in a lot of places, no?

Doing this separately in https://codereview.chromium.org/2298353002/.

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types_traits.cc (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types_traits.cc:31: if (!data.ReadFds(&handles))
On 2016/08/31 17:06:02, Fady Samuel wrote:
> GetFdsDataView and iterate directly inside the buffer instead of deserializing
> everything in on vector and then copying again?

Nice! Done. Thanks!

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types_traits.h (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types_traits.h:230: static std::vector<mojo::ScopedHandle>
fds(
On 2016/08/31 17:06:02, Fady Samuel wrote:
> This will create a copy of the vector which may be expensive. If this vector
is
> usually small, could you please say so in a comment?

We return a vector with a move here. I think that avoids the copy?

[rjkroege, 2016-08-31 19:54:14]

https://codereview.chromium.org/2298003002/diff/140001/services/ui/common/BUI...
File services/ui/common/BUILD.gn (right):

https://codereview.chromium.org/2298003002/diff/140001/services/ui/common/BUI...
services/ui/common/BUILD.gn:60: sources = []
so there's no test? this looks weird. What actually gets run?

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:55: int32 stride;
On 2016/08/31 16:52:36, Tom Sepez wrote:
> Can these be negative?  Would an unsigned type be more appropriate? Otherwise
we
> have to check for < 0 in a lot of places, no?

Also, I recall that for some overlay plane types, the stride might need to be
negative to make some planes (e.g. overlay planes scan out with the opposite
coordinate system from the GPU.)

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:65: array<NativePixmapPlane> planes;
On 2016/08/31 17:13:19, sadrul wrote:
> On 2016/08/31 17:04:15, Tom Sepez wrote:
> > Anyways, where do we check upon de-serialization that the combination of
> strides
> > and offsets etc. doesn't overflow the bounds of the underlying memory?
> 
> It doesn't look like we actually check that anywhere currently. The host (i.e.
> chrome browser, or the window server) receives these from the gpu process, and
> sends them off back to the clients (i.e. renderers) or processes them locally,
> without doing any bounds checking.

On CrOS, these values end up here:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/common/client_nati...


trying to think like a security reviewer for a moment: if !pwned client invokes
the client pixmap code with bad parameters from pwned gpu process (pixmap
handles always originate in gpu process) then there would seem to be two cases?
a) mmap is fragile and badness ensures or b) mmap is robust and client has
either done nothing (and handles the mmap error) or added a mapping for a
possibly over large area of memory that it will write raster image into.

Seems like the deserializer should test that size.height_* stride is > 0 and
complain bitterly if isn't.

[sadrul, 2016-08-31 20:01:28]

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
File ui/gfx/mojo/buffer_types.mojom (right):

https://codereview.chromium.org/2298003002/diff/140001/ui/gfx/mojo/buffer_typ...
ui/gfx/mojo/buffer_types.mojom:65: array<NativePixmapPlane> planes;
On 2016/08/31 19:54:14, rjkroege wrote:
> On 2016/08/31 17:13:19, sadrul wrote:
> > On 2016/08/31 17:04:15, Tom Sepez wrote:
> > > Anyways, where do we check upon de-serialization that the combination of
> > strides
> > > and offsets etc. doesn't overflow the bounds of the underlying memory?
> > 
> > It doesn't look like we actually check that anywhere currently. The host
(i.e.
> > chrome browser, or the window server) receives these from the gpu process,
and
> > sends them off back to the clients (i.e. renderers) or processes them
locally,
> > without doing any bounds checking.
> 
> On CrOS, these values end up here:
>
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/common/client_nati...
> 
> 
> trying to think like a security reviewer for a moment: if !pwned client
invokes
> the client pixmap code with bad parameters from pwned gpu process (pixmap
> handles always originate in gpu process) then there would seem to be two
cases?
> a) mmap is fragile and badness ensures or b) mmap is robust and client has
> either done nothing (and handles the mmap error) or added a mapping for a
> possibly over large area of memory that it will write raster image into.
> 
> Seems like the deserializer should test that size.height_* stride is > 0 and
> complain bitterly if isn't.

|size| doesn't come at the same time as the stride though, so perhaps we can't
do the validation during deserialization. Should we do more validation at the
place where we use these values (i.e. in
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/common/client_nati...)
instead?

[commit-bot: I haz the power, 2016-08-31 21:14:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 21:14:42]

Dry run: This issue passed the CQ dry run.

[sadrul, 2016-09-01 00:58:58]

sadrul@chromium.org changed reviewers:
+ reveman@chromium.org

[sadrul, 2016-09-01 00:58:59]

+reveman@ here too.

From https://codereview.chromium.org/2298353002/: it sounds like we do want to
support signed strides. So I have left these parts unchanged in this CL too.

It also looks like (https://codereview.chromium.org/2298003002/#msg44) we can't
really do validation during deserialization because we lack enough information
at that time. So we can do additional validation in
ClientNativePixmapDmaBuf::ClientNativePixmapDmaBuf() instead, where we actually
use this data. Would that be sufficient? Should I add additional validation
elsewhere?

[Tom Sepez, 2016-09-01 16:17:38]

> It also looks like (https://codereview.chromium.org/2298003002/#msg44) we
can't
> really do validation during deserialization because we lack enough information
> at that time. So we can do additional validation in
> ClientNativePixmapDmaBuf::ClientNativePixmapDmaBuf() instead, where we
actually
> use this data. Would that be sufficient? 
Seems reasonable.  Thanks.

[sadrul, 2016-09-01 20:37:35]

I have put up https://codereview.chromium.org/2302053003/ for the validation. I
believe that addresses all the outstanding blockers for this CL. This is ready
for review now. PTAL, thanks!

[Tom Sepez, 2016-09-01 20:39:27]

lgtm

[sadrul, 2016-09-02 02:33:31]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 02:33:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-02 02:36:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 02:36:42]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sadrul, 2016-09-02 02:47:13]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 02:47:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sadrul, 2016-09-02 02:58:22]

sadrul@chromium.org changed reviewers:
+ sky@chromium.org

[sadrul, 2016-09-02 02:58:23]

+sky@ for services/ui owner

[commit-bot: I haz the power, 2016-09-02 03:08:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 03:08:38]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sky, 2016-09-02 14:35:09]

LGTM assuming the test I mention isn't running on any bots.

https://codereview.chromium.org/2298003002/diff/200001/services/ui/common/BUI...
File services/ui/common/BUILD.gn (left):

https://codereview.chromium.org/2298003002/diff/200001/services/ui/common/BUI...
services/ui/common/BUILD.gn:61: test("mus_common_unittests") {
Does this not run on any bots?

[sadrul, 2016-09-02 14:44:03]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 14:44:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sadrul, 2016-09-02 14:45:58]

sadrul@chromium.org changed reviewers:
+ dpranke@chromium.org

[sadrul, 2016-09-02 14:45:59]

+dpranke@ for tools/determinism update.

https://codereview.chromium.org/2298003002/diff/200001/services/ui/common/BUI...
File services/ui/common/BUILD.gn (left):

https://codereview.chromium.org/2298003002/diff/200001/services/ui/common/BUI...
services/ui/common/BUILD.gn:61: test("mus_common_unittests") {
On 2016/09/02 14:35:08, sky wrote:
> Does this not run on any bots?

Doesn't look like it. There was one tool that was still referencing
mus_common_unittests (//tools/determinism/compare_build_artifacts.py), I removed
that from there.

[commit-bot: I haz the power, 2016-09-02 15:47:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 15:47:41]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Dirk Pranke, 2016-09-02 16:51:00]

lgtm

[sadrul, 2016-09-02 19:12:18]

The CQ bit was checked by sadrul@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 19:12:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sadrul, 2016-09-02 20:27:30]

The CQ bit was checked by sadrul@chromium.org

[sadrul, 2016-09-02 20:27:30]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org,
sky@chromium.org, dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/2298003002/#ps240001
(title: ".")

[commit-bot: I haz the power, 2016-09-02 20:27:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 20:27:37]

Dry run: This issue passed the CQ dry run.

[sadrul, 2016-09-02 20:31:23]

The CQ bit was checked by sadrul@chromium.org

[commit-bot: I haz the power, 2016-09-02 20:32:45]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-02 20:38:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 20:38:15]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[sadrul, 2016-09-02 22:01:52]

Description was changed from

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
==========

to

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change
==========

[sadrul, 2016-09-02 22:02:59]

The CQ bit was checked by sadrul@chromium.org

[commit-bot: I haz the power, 2016-09-02 22:03:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-02 22:09:32]

Description was changed from

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change
==========

to

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change
==========

[commit-bot: I haz the power, 2016-09-02 22:09:35]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-09-02 22:11:58]

Description was changed from

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change
==========

to

==========
gfx: Struct traits for GpuMemoryBufferHandle.

The remaining type-converter is for GpuMemoryBufferHandle. So introduce a
struct-trait for it instead. It also needs struct-traits for
NativePixmapPlane and NativePixmapHandle. Remove the type-converters,
since they are no longer needed. Also, expose NativePixmapPlane and
NativePixmapHandle types to non-ozone platforms, so we don't need some
special ozone-only mojom API.

BUG=637923
TBR=reveman@ for trivial components/exo change

Committed: https://crrev.com/5569cc1d0d05edce033dc92096ad5d5b03067907
Cr-Commit-Position: refs/heads/master@{#416362}
==========

[commit-bot: I haz the power, 2016-09-02 22:12:00]

Patchset 13 (id:??) landed as
https://crrev.com/5569cc1d0d05edce033dc92096ad5d5b03067907
Cr-Commit-Position: refs/heads/master@{#416362}