Date: Wed, 19 Dec 2012 14:50:13 -0500 From: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> To: freebsd-net@freebsd.org Subject: Re: use of V_tcbinfo lock for TCP syncache Message-ID: <50D21A75.1020403@gmail.com> In-Reply-To: <CALCNsJRFyQ9ZmfJ3quX2-cUuFHjs2rXw63Tq5ZH-uP1%2BoQmjLw@mail.gmail.com> References: <CALCNsJRFyQ9ZmfJ3quX2-cUuFHjs2rXw63Tq5ZH-uP1%2BoQmjLw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/12/2012 2:31 PM, Vijay Singh wrote: > As it is today, a socket upcall on a listener socket is made with the > V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn -> > sowakeup]. > > I feel that the use of the V_tcbinfo is not consistent in the syncache code. > > In syncache_add(), we drop the lock before doing the lookup: > > INP_WUNLOCK(inp); > INP_INFO_WUNLOCK(&V_tcbinfo); > [..snip..] > sc = syncache_lookup(inc, &sch); /* returns locked entry */ > > However, when going through syncache_expand() or syncache_chkrst() we > keep the V_tcbinfo lock. > > Since the syncache has its own lock, do we need to hold the V_tcbinfo > lock when calling syncache_socket()? > > Every time the list of TCP control blocks (tcbinfo) is manipulated, a write lock must be held to protect it. syncache_expand() is responsible for 'expanding' the listening socket into a full blown accepted socket, including creating its associated control block in the process. By the way I don't think V_tcbinfo lock is held for syncache_chkrst() or needed for that matter but I could be wrong since I'm looking at 7.x code. Karim.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50D21A75.1020403>