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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
