[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

HANDLE values are carried in Channel messages as PlatformHandles.
At various points in its lifetime, a PlaformHandle may actually
correspond to a HANDLE in another process's handle table - for example
when sending an outgoing message containing a handle, the handle is
duplicated to the target process and then serialized.

In some cases, a duplicated handle is never sent to the target
process (e.g. an outgoing message queued on a Channel but not
sent before the Channel is torn down). In such cases we were
blindly calling CloseHandle which is incorrect (see comments inside
CL).

This CL adds a field to PlatformHandle to track the process to
which the HANDLE belongs. In addition to being used for sanity
checks in RewriteHandles, this is also used to allow
PlatformHandle to do the right thing when closing a handle owned
by another process.

BUG=603280
R=amistry@chromium.org

Committed: https://crrev.com/0bcc20b48b02c2a84396f3e484da40303be0d5a4
Cr-Commit-Position: refs/heads/master@{#389693}

[Ken Rockot(use gerrit already), 2016-04-26 01:07:56]

Please take a look.

Note that because PlatformHandles are stored directly within message buffers,
the owning_process field is also carried in messages. This field's value within
one process is meaningless within another process, but removing it from messages
would be a lot more involved since we'd have to track owning process separately
for each handle in a message, and then reconstruct PlatformHandle objects on
Message destruction for unsent messages to get PlatformHandle's CloseIfNecessary
behavior.

For this reason, owning_process is explicitly rewritten on incoming
PlatformHandles based on the receivers knowledge about the sender. This may
immediately precede a call to RewriteHandles which then duplicates the handles
back to the current process. This is a little confusing to read at first, but I
don't see a much better solution.

[Ken Rockot(use gerrit already), 2016-04-26 01:09:15]

Description was changed from

==========
[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

HANDLE values are carried in Channel messages as PlatformHandles.
At various points in its lifetime, a PlaformHandle may actually
correspond to a HANDLE in another process's handle table - for example
when sending an outgoing message containing a handle, the handle is
duplicated to the target process and then serialized.

In some cases, a duplicated handle is never sent to the target
process (e.g. an outgoing message queued on a Channel but not
sent before the Channel is torn down). In such cases we were
blindly calling CloseHandle which is incorrect (see comments inside
CL).

This CL adds a field to PlatformHandle to track the process to
which the HANDLE belongs. In addition to being used for sanity
checks in RewriteHandles, closing a PlatformHandle now does the
right thing if the handle's owning process is not the calling process.

BUG=603280
R=amistry@chromium.org
==========

to

==========
[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

HANDLE values are carried in Channel messages as PlatformHandles.
At various points in its lifetime, a PlaformHandle may actually
correspond to a HANDLE in another process's handle table - for example
when sending an outgoing message containing a handle, the handle is
duplicated to the target process and then serialized.

In some cases, a duplicated handle is never sent to the target
process (e.g. an outgoing message queued on a Channel but not
sent before the Channel is torn down). In such cases we were
blindly calling CloseHandle which is incorrect (see comments inside
CL).

This CL adds a field to PlatformHandle to track the process to
which the HANDLE belongs. In addition to being used for sanity
checks in RewriteHandles, this is also used to allow
PlatformHandle to do the right thing when closing a handle owned
by another process.

BUG=603280
R=amistry@chromium.org
==========

[Anand Mistry (off Chromium), 2016-04-26 03:47:43]

lgtm

[Ken Rockot(use gerrit already), 2016-04-26 03:48:30]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-04-26 03:48:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1914053003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1914053003/1

[commit-bot: I haz the power, 2016-04-26 04:23:31]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-04-26 04:25:18]

Description was changed from

==========
[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

HANDLE values are carried in Channel messages as PlatformHandles.
At various points in its lifetime, a PlaformHandle may actually
correspond to a HANDLE in another process's handle table - for example
when sending an outgoing message containing a handle, the handle is
duplicated to the target process and then serialized.

In some cases, a duplicated handle is never sent to the target
process (e.g. an outgoing message queued on a Channel but not
sent before the Channel is torn down). In such cases we were
blindly calling CloseHandle which is incorrect (see comments inside
CL).

This CL adds a field to PlatformHandle to track the process to
which the HANDLE belongs. In addition to being used for sanity
checks in RewriteHandles, this is also used to allow
PlatformHandle to do the right thing when closing a handle owned
by another process.

BUG=603280
R=amistry@chromium.org
==========

to

==========
[mojo-edk] Fix lifetime management of rewritten Windows HANDLEs

HANDLE values are carried in Channel messages as PlatformHandles.
At various points in its lifetime, a PlaformHandle may actually
correspond to a HANDLE in another process's handle table - for example
when sending an outgoing message containing a handle, the handle is
duplicated to the target process and then serialized.

In some cases, a duplicated handle is never sent to the target
process (e.g. an outgoing message queued on a Channel but not
sent before the Channel is torn down). In such cases we were
blindly calling CloseHandle which is incorrect (see comments inside
CL).

This CL adds a field to PlatformHandle to track the process to
which the HANDLE belongs. In addition to being used for sanity
checks in RewriteHandles, this is also used to allow
PlatformHandle to do the right thing when closing a handle owned
by another process.

BUG=603280
R=amistry@chromium.org

Committed: https://crrev.com/0bcc20b48b02c2a84396f3e484da40303be0d5a4
Cr-Commit-Position: refs/heads/master@{#389693}
==========

[commit-bot: I haz the power, 2016-04-26 04:25:19]

Patchset 1 (id:??) landed as
https://crrev.com/0bcc20b48b02c2a84396f3e484da40303be0d5a4
Cr-Commit-Position: refs/heads/master@{#389693}