cvs commit: src/sys/kern uipc_socket.c

[Robert Watson]

On Wed, 15 Mar 2006, Alfred Perlstein wrote:

>>   Modified files:
>>     sys/kern             uipc_socket.c
>>   Log:
>>   As with socket consumer references (so_count), make sofree() return
>>   without GC'ing the socket if a strong protocol reference to the socket
>>   is present (SS_PROTOREF).
>
> This stuff is no end of complexity in the vfs layer V_DOOMED/V_whatever, 
> can't you accomplish this by just adding an additional reference from the 
> protocol layer?

Socket and PCB reference counting is currently Extraordinarily Complex and 
More Than A Little Broken.  This is the first in a long series of steps to 
migrate the socket and protocol code from an ad hoc reference system to a more 
pure reference system.  This includes:

- Transitioning so_pcb to being a protocol-only field, instead of allowing the
   socket layer to use it.  SS_PROTOREF is, in effect, replacing so_pcb as a
   reference visible to the socket layer.

- Moving towards an invariant that so_pcb is non-NULL for the life time of a
   socket for most protocol, allowing us to remove the constant checking for a
   NULL so_pcb (and associated locking) throughout the protocols.  This
   involves a significant rewrite of TCP's pcb use, as we currently discard the
   PCB long before the socket is freed, hence significant complexity in all the
   TCP protocol APIs exposed to the socket layer.

- Guaranteeing that pru_detach() will only be called once per socket, and only
   if pru_attach() succeeded.

- Eliminating unused failure modes, such as the failure of pru_detach() and
   pru_abort().

- Fixing a large number of race conditions and bugs in the TCP tcpcb and twpcb
   model.

I would like to get to the point where so_count is the sole reference count on 
the socket, but it will take quite a bit of work to get there.  You can find 
an outstanding, if somewhat dated, patch at:

     http://www.watson.org/~robert/freebsd/netperf/20060228-rwatson_sockref.diff

Cleaning up and merging large parts of this is waiting on a couple of things, 
including updates to the bluetooth code (I've contacted emax already), and 
also on a determination of the future of netatm.  I have changes in that patch 
to make netatm compile, but I'm unable to test it, and fairly sure there is 
more to be done there.

Robert N M Watson