[NaCl SDK] nacl_io: Add support for basic socketpairs.

[NaCl SDK] nacl_io: Add support for basic socketpairs.

This is a very basic implementation of a unix socketpair. The socket
nodes have type S_IFSOCK.

The event emitter are set up in a master/slave configuration, the master
owns the fifos and slave handles. The slave has a strong reference to
its master (since it depends on it, cannot survive alone). Each emitter
in the pair has their own status, but share the pair of fifos and use a
single lock in the master to synchronize their access.

Shutdown should be rather simple to bolt on to this implementation.

CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_nacl_sdk;tryserver.chromium.mac:mac_nacl_sdk
BUG=532095
Committed: https://crrev.com/e40c14e14250a5b3ea235ae0ec846b84d2be73ae
Cr-Commit-Position: refs/heads/master@{#350849}

[avallee, 2015-09-15 20:37:40]

avallee@chromium.org changed reviewers:
+ binji@chromium.org, bradnelson@chromium.org, sbc@chromium.org

[avallee, 2015-09-15 20:37:40]

PTAL.

[binji, 2015-09-17 01:03:58]

Looks great so far, thanks for doing this!

I'd like to see a quick test showing this working, but the structure looks good
to me.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:1: //
Copyright (c) 2013 The Chromium Authors. All rights reserved.
Fix year
remove (c)

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:22:
UnixMasterEventEmitter(size_t size)
explicit

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:49:
UnixChildEventEmitter(UnixMasterEventEmitter* parent)
explicit

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:81: if
(peer) {
when would this be NULL?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:91: if
(peer) {
It looks like the order of updating status of this vs. peer matters here. Could
you elaborate why?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h:1: 
missing line?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h:27: // bool
GetError_Locked();
remove

[Sam Clegg, 2015-09-17 09:40:39]

Thanks for working on this!

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc (right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc:1879: return -1;
Can you use early return if domain != AF_UNIX then remove nesting of the success
(return 0) path?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.cc
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.cc:62: if
(src_addr) {
Can you construct a sockaddr_un here?  Perhaps with sun_path set to '\0'?   Or
perhaps we don't have un.h available on all platforms? 

Perhaps a helper function like ResourceToSockAddr()?

Perhaps RecvHelper should be made to take sockaddr_t rather than a PP_Resource,
although I guess that could be a later change.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h:19:
explicit UnixSocketpairNode(Filesystem* filesystem);
Should we just call this UnixSocketNode, since it doesn't represent the both
nodes in the pair does it?

How about "unixsocket_node.h"?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
File native_client_sdk/src/tests/nacl_io_test/mock_node.cc (right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
native_client_sdk/src/tests/nacl_io_test/mock_node.cc:10: ON_CALL(*this,
GetType()).WillByDefault(Return(S_IFREG));
Why this change?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
File native_client_sdk/src/tests/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
native_client_sdk/src/tests/nacl_io_test/socket_test.cc:267: EXPECT_GE(sv[1],
0);
More testing here would be good.  Perhaps a split into several socketpair tests?
  If there is a lot of test code perhaps we can somehow share tests/code with
the TCP tests?

Oh, I just remembered that the TCP/UDP socket tests all live in the
nacl_io_socket_test suite which runs in chrome since we don't have mocks for the
socket API.  However, socketpair tests don't rely on pepper so should all be
testable under sel_ldr here in nacl_io_test.

[avallee, 2015-09-17 16:18:01]

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:81: if
(peer) {
On 2015/09/17 01:03:57, binji wrote:
> when would this be NULL?

It could be NULL if we never create a child emitter (if we reused the node code
and did not create a socketpair). This can also happen once the child node
reference count drops to 0, in which case it will set the child pointer to NULL
in its parent (line 56).

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:91: if
(peer) {
On 2015/09/17 01:03:58, binji wrote:
> It looks like the order of updating status of this vs. peer matters here.
Could
> you elaborate why?

I don't *think* the order matters. However my initial intuition is that both
nodes would initially block on read and we may want to unblock them as early as
possible.

I would think Read should also update the peer first, to allow a write to
continue writing before returning to caller.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.cc
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.cc:62: if
(src_addr) {
On 2015/09/17 09:40:39, Sam Clegg wrote:
> Can you construct a sockaddr_un here?  Perhaps with sun_path set to '\0'?   Or
> perhaps we don't have un.h available on all platforms? 
> 
> Perhaps a helper function like ResourceToSockAddr()?
> 
> Perhaps RecvHelper should be made to take sockaddr_t rather than a
PP_Resource,
> although I guess that could be a later change.

I can't seem to find sys/un.h on platforms including pnacl (my main use case for
adb).

I've messed around with a small test program on my workstation:
get{sock,peer}name returns addr.sun_family == AF_UNIX and does not modify
addr.sun_path (not even writing sun_path[0] = '\0'). The returned socklen value
is 2, sizeof(sun_family).

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h:19:
explicit UnixSocketpairNode(Filesystem* filesystem);
On 2015/09/17 09:40:39, Sam Clegg wrote:
> Should we just call this UnixSocketNode, since it doesn't represent the both
> nodes in the pair does it?
> 
> How about "unixsocket_node.h"?

Sounds fair.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
File native_client_sdk/src/tests/nacl_io_test/mock_node.cc (right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/tests...
native_client_sdk/src/tests/nacl_io_test/mock_node.cc:10: ON_CALL(*this,
GetType()).WillByDefault(Return(S_IFREG));
On 2015/09/17 09:40:39, Sam Clegg wrote:
> Why this change?

Might not be needed, but both read and write now call gettype (via IsSeekable in
my previous patch). The natural intuition is that the default file node type is
a regular file. The original unset value 0, is never a valid file type and
should not have this value.

In the test that expects a directory, I added an expect_call (which probably
should also be ON_CALL if that works) to suppress some warnings.

[avallee, 2015-09-17 19:00:31]

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc (right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc:1879: return -1;
On 2015/09/17 09:40:39, Sam Clegg wrote:
> Can you use early return if domain != AF_UNIX then remove nesting of the
success
> (return 0) path?

Done.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:1: //
Copyright (c) 2013 The Chromium Authors. All rights reserved.
On 2015/09/17 01:03:57, binji wrote:
> Fix year
> remove (c)

Done.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:22:
UnixMasterEventEmitter(size_t size)
On 2015/09/17 01:03:57, binji wrote:
> explicit

Done.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.cc:49:
UnixChildEventEmitter(UnixMasterEventEmitter* parent)
On 2015/09/17 01:03:58, binji wrote:
> explicit

Done.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h:1: 
On 2015/09/17 01:03:58, binji wrote:
> missing line?

Done.

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_event_emitter.h:27: // bool
GetError_Locked();
On 2015/09/17 01:03:58, binji wrote:
> remove

Done.

[avallee, 2015-09-18 19:46:25]

PTAL.

[binji, 2015-09-18 23:30:13]

lgtm, w/ class name change.

Sam, do you have any other concerns?

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h
(right):

https://codereview.chromium.org/1335783005/diff/1/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_io/socket/unix_socketpair_node.h:19:
explicit UnixSocketpairNode(Filesystem* filesystem);
On 2015/09/17 at 16:18:01, avallee wrote:
> On 2015/09/17 09:40:39, Sam Clegg wrote:
> > Should we just call this UnixSocketNode, since it doesn't represent the both
> > nodes in the pair does it?
> > 
> > How about "unixsocket_node.h"?
> 
> Sounds fair.

Please rename the class as well.

[avallee, 2015-09-21 16:49:50]

sbc: mind a quick peek again?

[Sam Clegg, 2015-09-22 17:53:44]

Great thanks!  lgtm with a few nits.

Can you add the following line to the CL description so that the correct trybots
are used by the CQ:
CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_nacl_sdk;tryserver.chromium.mac:mac_nacl_sdk;tryserver.chromium.win:win_nacl_sdk

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
File native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc:1823: errno =
EPROTONOSUPPORT;
Can you combine the these two conditionals?   Is EPROTONOSUPPORT really the
correct error here?    Should we also check for supported 'protocol'?

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
File native_client_sdk/src/libraries/nacl_io/socket/unixsocket_event_emitter.h
(right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
native_client_sdk/src/libraries/nacl_io/socket/unixsocket_event_emitter.h:17:
class UnixEventEmitter;
Sorry, I think that the callname should match the filename so if you want to
keep this filename then the class should be UnixSocketEventEmitter.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/kernel_proxy_test.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/kernel_proxy_test.cc:1096:
EXPECT_CALL(*mock_node, GetType()).WillRepeatedly(Return(S_IFDIR));
Why is this change needed?

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/mock_node.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/mock_node.cc:10: ON_CALL(*this,
GetType()).WillByDefault(Return(S_IFREG));
Why?

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/socket_test.cc:246: TEST_F(SocketTest,
Socket) {
Perhaps rename this test SocketUnsupported?  And the test below
SocketpairUnsupported?

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/socket_test.cc:315: EXPECT_EQ(0,
memcmp(outbuf, inbuf, sizeof(outbuf)));
Perhaps confirm that ki_recv with MSG_DONTWAIT yields EAGAIN here?

Also can you confirm that you can send data back the other way too?

[avallee, 2015-09-22 20:25:06]

PTAL

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
File native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
native_client_sdk/src/libraries/nacl_io/kernel_proxy.cc:1823: errno =
EPROTONOSUPPORT;
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Can you combine the these two conditionals?   Is EPROTONOSUPPORT really the
> correct error here?    Should we also check for supported 'protocol'?

Good point, I read the socketpair page many times to make sure the errors made
sense, but EPROTONOSUPPORT means family/protocol mismatch. Currently this means
AF_UNIX/SOCK_DGRAM is EPROTONOSUPPORT

Every other family should return EAFNOSUPPORT if we don't support it and
EOPNOTSUPP if we somehow support the family, but not for socketpairs.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
File native_client_sdk/src/libraries/nacl_io/socket/unixsocket_event_emitter.h
(right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/l...
native_client_sdk/src/libraries/nacl_io/socket/unixsocket_event_emitter.h:17:
class UnixEventEmitter;
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Sorry, I think that the callname should match the filename so if you want to
> keep this filename then the class should be UnixSocketEventEmitter.

I'm going to rename the files back to unix_{node,event_emitter}. This is shorter
and they are already under socket/

Should the files in socket/ all live under namespace socket? That's a different
CL.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/kernel_proxy_test.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/kernel_proxy_test.cc:1096:
EXPECT_CALL(*mock_node, GetType()).WillRepeatedly(Return(S_IFDIR));
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Why is this change needed?

I'll split this out to a separate CL, this was a change that should have been
made in my previous CL.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/mock_node.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/mock_node.cc:10: ON_CALL(*this,
GetType()).WillByDefault(Return(S_IFREG));
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Why?

Removed, not necessary.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
File native_client_sdk/src/tests/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/socket_test.cc:246: TEST_F(SocketTest,
Socket) {
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Perhaps rename this test SocketUnsupported?  And the test below
> SocketpairUnsupported?

Done.

https://codereview.chromium.org/1335783005/diff/60001/native_client_sdk/src/t...
native_client_sdk/src/tests/nacl_io_test/socket_test.cc:315: EXPECT_EQ(0,
memcmp(outbuf, inbuf, sizeof(outbuf)));
On 2015/09/22 17:53:44, Sam Clegg wrote:
> Perhaps confirm that ki_recv with MSG_DONTWAIT yields EAGAIN here?
> 
> Also can you confirm that you can send data back the other way too?

Added and sent data in the opposite direction as well.

[Sam Clegg, 2015-09-22 20:58:30]

lgtm thanks.

Can you update the CL description to include the CQ_EXTRA_TRYBOTS?

[avallee, 2015-09-22 21:04:06]

The CQ bit was checked by avallee@chromium.org

[avallee, 2015-09-22 21:04:07]

The patchset sent to the CQ was uploaded after l-g-t-m from binji@chromium.org
Link to the patchset: https://codereview.chromium.org/1335783005/#ps80001
(title: " ")

[commit-bot: I haz the power, 2015-09-22 21:06:55]

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

[commit-bot: I haz the power, 2015-09-22 21:14:45]

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

[commit-bot: I haz the power, 2015-09-22 21:14:46]

Try jobs failed on following builders:
  win_nacl_sdk                                                                  
                                                                                
                                                                                
                                on tryserver.chromium.win (JOB_FAILED, no build
URL)

[avallee, 2015-09-23 19:33:36]

The CQ bit was checked by avallee@chromium.org

[commit-bot: I haz the power, 2015-09-23 19:35:47]

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

[commit-bot: I haz the power, 2015-09-23 19:42:01]

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

[commit-bot: I haz the power, 2015-09-23 19:42:01]

Try jobs failed on following builders:
  win_nacl_sdk                                                                  
                                                                                
                                                                                
                                on tryserver.chromium.win (JOB_FAILED, no build
URL)

[Sam Clegg, 2015-09-23 19:56:36]

The CQ bit was checked by sbc@chromium.org

[commit-bot: I haz the power, 2015-09-23 19:57:52]

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

[commit-bot: I haz the power, 2015-09-23 20:07:18]

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

[commit-bot: I haz the power, 2015-09-23 20:07:19]

Try jobs failed on following builders:
  win_nacl_sdk                                                                  
                                                                                
                                                                                
                                on tryserver.chromium.win (JOB_FAILED, no build
URL)

[avallee, 2015-09-24 00:44:38]

Removed the windows win_nacl_sdk try request from CQ as it seems broken in CQ,
but succeeds when manually requesting.

[avallee, 2015-09-24 00:44:46]

The CQ bit was checked by avallee@chromium.org

[commit-bot: I haz the power, 2015-09-24 00:46:09]

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

[commit-bot: I haz the power, 2015-09-24 02:41:18]

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

[commit-bot: I haz the power, 2015-09-24 02:41:19]

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

[Sam Clegg, 2015-09-24 19:20:31]

The CQ bit was checked by sbc@chromium.org

[commit-bot: I haz the power, 2015-09-24 19:22:51]

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

[commit-bot: I haz the power, 2015-09-24 20:47:27]

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

[commit-bot: I haz the power, 2015-09-24 20:47:28]

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

[avallee, 2015-09-25 14:38:16]

The CQ bit was checked by avallee@chromium.org

[commit-bot: I haz the power, 2015-09-25 14:38:33]

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

[commit-bot: I haz the power, 2015-09-25 16:54:30]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-09-25 16:55:16]

Patchset 5 (id:??) landed as
https://crrev.com/e40c14e14250a5b3ea235ae0ec846b84d2be73ae
Cr-Commit-Position: refs/heads/master@{#350849}

[cmumford, 2015-09-25 18:12:42]

A revert of this CL (patchset #5 id:80001) has been created in
https://codereview.chromium.org/1373563003/ by cmumford@chromium.org.

The reason for reverting is: undefined reference to
'nacl_io::UnixNode::UnixNode(nacl_io::Filesystem*, nacl_io::UnixNode const&)'.