Fix lock-order-inversion in ChannelMojo

Fix lock-order-inversion in ChannelMojo

The following lock sequences are possible:

 1. ChannelMojo lock (A) is held for Connect when calling
    bootstrap_->Connect(), which in turn binds the
    Binding, starting a MojoWatch which locks the internal
    lock (B) for the watcher. So A => B.

 2. An incoming IPC wakes the watcher (B) and calls
    SyncMessageFilter::OnMessageReceived which locks SMF's
    lock (C). So B => C.

 3. Sending an IPC locks SMF's lock (C) and then locks
    ChannelMojo's lock (A) while holding C. So C => A.

This CL eliminates the A => B => C => A cycle by avoiding
case 1. There's no need to hold ChannelMojo's lock while
connecting the Bootstrap.

BUG=606701
R=amistry@chromium.org

Committed: https://crrev.com/6897439afeea04f28bb3bc2f9573d47b1e232eeb
Cr-Commit-Position: refs/heads/master@{#390880}

[Anand Mistry (off Chromium), 2016-05-01 23:57:49]

The CQ bit was checked by amistry@chromium.org

[Anand Mistry (off Chromium), 2016-05-01 23:57:50]

lgtm

[commit-bot: I haz the power, 2016-05-01 23:57:58]

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

[commit-bot: I haz the power, 2016-05-02 00:02:30]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-02 00:03:39]

Description was changed from

==========
Fix lock-order-inversion in ChannelMojo

The following lock sequences are possible:

 1. ChannelMojo lock (A) is held for Connect when calling
    bootstrap_->Connect(), which in turn binds the
    Binding, starting a MojoWatch which locks the internal
    lock (B) for the watcher. So A => B.

 2. An incoming IPC wakes the watcher (B) and calls
    SyncMessageFilter::OnMessageReceived which locks SMF's
    lock (C). So B => C.

 3. Sending an IPC locks SMF's lock (C) and then locks
    ChannelMojo's lock (A) while holding C. So C => A.

This CL eliminates the A => B => C => A cycle by avoiding
case 1. There's no need to hold ChannelMojo's lock while
connecting the Bootstrap.

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

to

==========
Fix lock-order-inversion in ChannelMojo

The following lock sequences are possible:

 1. ChannelMojo lock (A) is held for Connect when calling
    bootstrap_->Connect(), which in turn binds the
    Binding, starting a MojoWatch which locks the internal
    lock (B) for the watcher. So A => B.

 2. An incoming IPC wakes the watcher (B) and calls
    SyncMessageFilter::OnMessageReceived which locks SMF's
    lock (C). So B => C.

 3. Sending an IPC locks SMF's lock (C) and then locks
    ChannelMojo's lock (A) while holding C. So C => A.

This CL eliminates the A => B => C => A cycle by avoiding
case 1. There's no need to hold ChannelMojo's lock while
connecting the Bootstrap.

BUG=606701
R=amistry@chromium.org

Committed: https://crrev.com/6897439afeea04f28bb3bc2f9573d47b1e232eeb
Cr-Commit-Position: refs/heads/master@{#390880}
==========

[commit-bot: I haz the power, 2016-05-02 00:03:40]

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

[Ken Rockot(use gerrit already), 2016-05-02 00:51:46]

Thanks for CQ