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
Loading
Please sign in to comment