Accessing socket APIs soon after accept

John Baldwin jhb at freebsd.org
Fri Feb 27 19:19:04 UTC 2015


On Friday, February 27, 2015 10:32:17 AM Adrian Chadd wrote:
> On 27 February 2015 at 10:07, John Baldwin <jhb at freebsd.org> wrote:
> > On Friday, February 27, 2015 10:03:33 AM Adrian Chadd wrote:
> >> Is this also a bug on -9 and -10?
> > 
> > Yes.  I may merge just the tcp_syncache.c part of this change down to
> > stable branches.
> 
> Cool, thanks.
> 
> Placing half-completed connections on the queue always looked a bit odd to
> me..

So this appears stranger.  Supposedly, the tcbinfo global lock should have 
fixed this race.

In particular, in 8.x, tcp_intput holds a write lock on the tcbinfo lock 
around all of syncache_expand() including all of syncache_socket() from 
sonewconn() on down to the end of the function not releasing it until after 
the addresses are all set, etc.  tcp_usr_accept() on 8.x acquires a read lock 
on the tcbinfo global lock, so if accept() races with syncache_socket(), even 
though accept() might dequeue the socket from sq_comp before the socket is 
fully constructed, the call to soaccept() inside of accept() should call 
tcp_usr_accept() which will try to read-lock the tcbinfo lock and will thus 
block until syncache_socket() has completed.  Thus, you shouldn't be able to 
have accept() return before syncache_socket() has finished.

-- 
John Baldwin


More information about the freebsd-net mailing list