Mojo EDK: Work around Nexus 9 hardware bug

mojo/edk/system/ports/node.cc

Index: mojo/edk/system/ports/node.cc
diff --git a/mojo/edk/system/ports/node.cc b/mojo/edk/system/ports/node.cc
index 186e8aaad95795f6f608555a0d7c16d17a73db40..daebb5bb610b5ca65fc4572af54a9e2a4d82c464 100644
--- a/mojo/edk/system/ports/node.cc
+++ b/mojo/edk/system/ports/node.cc
@@ -626,8 +626,8 @@ int Node::OnObserveProxyAck(const PortName& port_name,
 int Node::OnObserveClosure(const PortName& port_name,
                            uint64_t last_sequence_num) {
   // OK if the port doesn't exist, as it may have been closed already.
-  scoped_refptr<Port> port = GetPort(port_name);
-  if (!port)
+  scoped_refptr<Port> closed_port = GetPort(port_name);
+  if (!closed_port)
     return OK;
 
   // This message tells the port that it should no longer expect more messages
@@ -639,6 +639,12 @@ int Node::OnObserveClosure(const PortName& port_name,
   ObserveClosureEventData forwarded_data;
   NodeName peer_node_name;
   PortName peer_port_name;
+
+  // NOTE: This redundant copy of the scoped_refptr is here as a workaround for
+  // https://crbug.com/665869. Without it a code sequence is generated which
+  // under certain conditions can tickle a Tegra K1 erratum, causing the lock
+  // acquisition below to segfault.
+  scoped_refptr<Port> port = closed_port;

[Torne, 2016/11/18 11:59:56]

Doing this here isn't sufficient - there are also crashes occurring in the other
functions in this file that call GetPort, so whatever weird hack we introduce
should probably be inside GetPort.

It's weird that adding another scoped_refptr here works. I guess it's just
spreading things out enough that the out-of-order execution engine isn't making
whatever mistake it was making any more due to the changed input.

You might find that it's more efficient to add a MemoryBarrier() call somewhere
instead of making an extra refptr. My comment in the bug about creating the
scoped_refptr including a barrier is wrong - incrementing a refcount doesn't use
a barrier, only decrementing does, which doesn't happen until after the bug was
observed - so adding a barrier might be enough.

   bool try_remove_proxy = false;
   {
     base::AutoLock lock(port->lock);