Commit eeb3b74d authored by Przemyslaw Szczepaniak's avatar Przemyslaw Szczepaniak
Browse files

Remove AbstractPlainSocketImpl deferred close by dup2

AbstractPlainSocket was maintaining a counter for
threads using the socket fd. If someone was using
the socket fd (expressed by calling acquireFD/releaseFD methods),
close() would call dup2(marker, socketFd) and defer real close to
be done on the last releaseFD call. Now, marker was a AF_UNIX
socket pointing to no-where, and SELinux is not happy with
the accept call happening on it.

Comments in the code explain how they are doing it, but there's no
hint of why. IMHO it's a defense mechanism for badly written socket code.
Probably.

Close from concurrent thread will wake up the accept
thread (blocked on poll in NET_Timeout) and dup2
the marker to the the socket file descriptor. SELinux
will cause the accept function to return EPERM. This was
interpreted as a failure in both libcore.java.net.ConcurrentCloseTest#test_accept
and #test_connect_timeout.

This change removes the deferred close mechanism completely,
we call close on the socket file descriptor and depend
on the OS to handle the situation properly.

All ConcurrentCloseTest tests are passing, so it looks like
code sections protected with acquireFD/releaseFD are fine
with a concurrent close called in the other thread.

There's a plan B in case where this change breaks something,
openjdk was using INET socket instead of UNIX one, we can
revert to this solution, but it's hideously complex and
I would prefer to avoid it.

Bug: 26024365
Bug: 26127752
Change-Id: I0634faa5f519cdabcd6db56607bf1ae5c185dc84
parent 6e8e7241
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment