Hans: Take a look at the comments maybe they will help you understand whats going on.
The idea of it is that you *only* need the INFO_RLOCK when the timer function wants to destroy the tcb (not all timers do this).. and yes usually the timer function is going to call the drop/close path to purge the TCB. So in order to pick-up the info lock you do the refcnt/lock-dance to get both locks in the proper lock order. This means that someone could possibly come in and purge the tcb on you while you are in the process of doing the lock-dance. If that occurs (the return code is 1) all the caller has to do is call the drop-lock function (the mate to the add_lock) and then return (since the pcb is in the state the caller wants.. i.e. gone). If the return code is 0, the caller can proceed to purge the tcb.. and then call the drop_lock function. Note that in theory this could be used outside of wanting to kill the tcb.. but I am not sure why one would want to hold the INFO_RLOCK if one did not want to purge the tcb. R > On Aug 16, 2016, at 6:14 AM, Hans Petter Selasky <h...@selasky.org> wrote: > > On 08/16/16 15:01, Randall Stewart wrote: >> Sure >> >> Let me add some comments for you. The idea her is that you pick-up a >> reference >> to the PCB.. so it can’t be removed. Thus when you re-lock the INP you check >> the >> dropped flag (just in case someone did get in). > > And this code is only used before tcp_close() / tcp_drop(), so if others got > in it is safe to assume that the inp is dead? > > --HPS -------- Randall Stewart r...@netflix.com 803-317-4952 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
