SMP: protocol control block protection for a multithreaded process (ex: udp).

[Robert Watson]

On Tue, 29 May 2012, vasanth rao naik sabavat wrote:

> In case of a Multicore cpu system running a multithreaded process.
>
> For protocol control blocks there is no protection provided in the FreeBSD 
> 9. For example, udp_close() and udp_send() access the inp before taking the 
> lock. Couldn't this cause the inp inconsistency on a multithreaded process 
> running on multicore cpu system?
>
> Say, If the two threads of a process are concurrently executing socket send 
> and socket close say on a udp connection (this can happen in case of poorly 
> written user code.). udp_close() will access the inp on one cpu and 
> udp_send() will access the inp on another cpu. it is possible that 
> udp_close() gets the locks first and free's the inp before udp_send() has a 
> chance to run?
>
> Am I missing anything?

The life cycle here is complicated and there is some subtlety.  The simple 
answer to your question is that udp_abort() and udp_close() don't free the 
inpcb -- that occurs in udp_detach(), which is called only when the reference 
count on the socket hits 0, which can't happen while udp_send() is in flight, 
as the caller owns a reference maintaining the stability of the socket.

Take a look at the comment at the top of uipc_socket.c for more detailed 
coverage of socket life cycles; for UDP, inpcbs are around for the entirely 
life cycle of the socket, so it is always safe to follow so->so_pcb if you 
hold a valid socket reference (either borrowed from a process's file 
descriptor, or held).  For TCP, things are more complex.

Robert