use of V_tcbinfo lock for TCP syncache

[Navdeep Parhar]

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... :-)