svn commit: r304218 - head/sys/netinet

[Randall Stewart]

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 <hps at 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
rrs at netflix.com
803-317-4952