> Sure but syncache_expand() is entered with the tcbinfo already write locked > which also protects the unlocking of the listening connection and the > locking of the newly created socket. Around this part: > > /* > * Socket is created in state SYN_RECEIVED. > * Unlock the listen socket, lock the newly > * created socket and update the tp variable. > */ > INP_WUNLOCK(inp); /* listen socket */ > inp = sotoinpcb(so); > INP_WLOCK(inp); /* new connection */ > tp = intotcpcb(inp); > > Without the tcbinfo lock the new socket could be closed (getting a reset) > which would put it in INP_TIMEWAIT or INP_DROPPED _after_ the check is made > in tcp_usr_accept since there is a period of time where tcbinfo is not > locked and the new socket inp is not locked either. > > I could be wrong but it seems that without the tcbinfo lock a lot could > happen between the unlocking of the listen socket and the locking of the new
Hopefully Robert will chime in. I am sorry that I was not clear. In my experiment, syncache_expand() is still entered with the V_tcbinfo lock held. In my (limited) view, sonewconn() is overleaded. It [1] allocates a new socket [2] initializes it using the listener socket [3] invokes the pru_attach routine, where the inp is allocated [4] it inserts the socket in the listeners queue [5] it, optionally, notifies the listener of the new connection When sonewconn returns, we do a bunch of things, [6] such as call in_pcbconnect() and set state in tp etc. What I am experimenting with is to separate out [4] & [5] from the list above, and move those to AFTER we do the inp processing in [6]. At that point I do not think that the pcbinfo lock should be required to be held. -vijay _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
