net: Listener sometimes accepts connections after Close

[prashantv]

I've written a repro test here:
https://github.com/prashantv/listener-repro/blob/master/main.go

It basically does the following:

• Start a listener
• Create connectionsBeforeClose connections to the listener (which should succeed)
• Close the listener
• Create another connection to the listener

On the listener side, I expect to receive at most connectionsBeforeClose successful connections. Any extra connections causes the runTest method to return an error.

This works as expected on OSX, but on Linux, it seems to receive a successful connection after the listener has been closed.

Some things I noticed:

• If connectionsBeforeClose is set to 0, then no unexpected connections are made after the listener is closed
• The issue also disappears if I enableSleep

I would expect that a Listener will not accept any further socket attempts after Close has returned.

[mikioh]

This is a platform-indepedent issue and a duplicate of #10527.

[prashantv]

@mikioh I saw #10527, but I think this is a little different. #10527 is basically that the socket isn't closed since Accept has a reference to the underlying socket. However, the Accept should return an error when it is scheduled since the socket is closed.

In this case, Accept is not returning an error after the Close call. If you run the repro code, you'll see that it only fails on Linux and not OSX, so I'm not sure if this is a platform independent issue.

[mikioh]

@prashantv,

Thanks for the notice, hm, perhaps we need to dig accept4 more on both Linux and FreeBSD.

[mikioh]

@prashantv,

To conclude, this is a duplicate of #10527. In general this may happen when the shared fdMutex in TCPListener is taken by acceptor goroutine prior to TCPListener.Close like the following:

• goroutine1: calls netFD.Close. Close sets the state to closed and increments and decrements the ref count, but decref doesn't call netFD.destroy because goroutine2 has a readlock.

See #10527 for further information.

[prashantv]

@mikioh Ah, I thought that perhaps Accept would check whether the socket was marked as Closed but that doesn't affect epoll from accepting new connections.

It looks like the other issue has not had any progress since it was last marked as possibly for go 1.5. Can #10527 be prioritized for go 1.7? Thanks