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