Date: Tue, 29 May 2012 22:04:52 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: vasanth rao naik sabavat <vasanth.raonaik@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: SMP: protocol control block protection for a multithreaded process (ex: udp). Message-ID: <alpine.BSF.2.00.1205292202040.15505@fledge.watson.org> In-Reply-To: <CAAuizBjhGUUH3D3XN1t7WMnOPTq0vZjnV1QXGrR99qBOD34rGQ@mail.gmail.com> References: <CAAuizBjhGUUH3D3XN1t7WMnOPTq0vZjnV1QXGrR99qBOD34rGQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1205292202040.15505>