Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2012 13:01:35 -0800
From:      Vijay Singh <vijju.singh@gmail.com>
To:        Navdeep Parhar <nparhar@gmail.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: use of V_tcbinfo lock for TCP syncache
Message-ID:  <CALCNsJS8j0wvv4dc1Q6rLckmr0RE%2BgW0%2BmUDdmSvyfjXzKugsQ@mail.gmail.com>
In-Reply-To: <50D21C3B.8020803@gmail.com>
References:  <CALCNsJRFyQ9ZmfJ3quX2-cUuFHjs2rXw63Tq5ZH-uP1%2BoQmjLw@mail.gmail.com> <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>> Holding the pcbinfo lock prevents races between syncache_socket() and
>> accept().  See rwatson's comment just above tcp_usr_accept.  I noted
>> this too (the comment above tod->tod_offload_socket() in tcp_syncache.c)
>> back when I updated the TOE code in the kernel.
>
> er, I think I told you why tcp_usr_accept holds the pcbinfo lock, which
> wasn't your original question... :-)

But it helped.

So I am thinking about trying a change where syncache_socket() would
call soalloc() first, get a socket, setup the inp, and then do a
(modified) sonewconn to place the socket in the listener's queue.
Robert's comment indicated that this would be a better way to
eliminate the race since we wouldn't need the pcblock when we make the
sonewconn call.

-vijay



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALCNsJS8j0wvv4dc1Q6rLckmr0RE%2BgW0%2BmUDdmSvyfjXzKugsQ>