Close Syscall for sockets can deadlock if other thread is in blocking network call

[qianxichen233]

Description

close_syscall on a socket could block when another thread/cage is waiting for connections with accept_syscall or attempts a blocking send() using same duplicated socket file descriptor. This behavior is not expected. To reproduce:

1. create a client socket and server socket (AF_INET)
2. make a fork, now both client and server sockets were duplicated
3. on server cage, close the client socket, then let the server socket accept
4. on client cage, close the server socket, then connect to the server
5. if accept on server cage is called before close on client cage, deadlock would occur

Why this behavior

The reason being that the sockethandler is hold with read access for the entire time the server socket is waiting for connection in accept, and in close, a write access needs to be acquired in order to decrement its pipe reference counter. So that would mean if a socket is accept for some connections, close the same duplicated socket on another thread/cage would block until accept is finished, which could cause some program undergo unexpected deadlock (the example above).

How is this tested?

This behavior is tested and confirmed in c, that no blocking should be produced on close when another thread is calling accept