From owner-freebsd-hackers@FreeBSD.ORG Tue May 29 21:04:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BA43106566B for ; Tue, 29 May 2012 21:04:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 604C38FC14 for ; Tue, 29 May 2012 21:04:53 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0C9F246B09; Tue, 29 May 2012 17:04:53 -0400 (EDT) Date: Tue, 29 May 2012 22:04:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: vasanth rao naik sabavat In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: SMP: protocol control block protection for a multithreaded process (ex: udp). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 21:04:53 -0000 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