Date: Wed, 19 Dec 2012 11:57:47 -0800 From: Navdeep Parhar <nparhar@gmail.com> To: Vijay Singh <vijju.singh@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: use of V_tcbinfo lock for TCP syncache Message-ID: <50D21C3B.8020803@gmail.com> In-Reply-To: <50D218BA.7080301@FreeBSD.org> References: <CALCNsJRFyQ9ZmfJ3quX2-cUuFHjs2rXw63Tq5ZH-uP1%2BoQmjLw@mail.gmail.com> <50D218BA.7080301@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/19/12 11:42, Navdeep Parhar wrote: > On 12/19/12 11:31, 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()? > > 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... :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50D21C3B.8020803>