From owner-freebsd-hackers@FreeBSD.ORG Tue May 29 14:53:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAD11106566B for ; Tue, 29 May 2012 14:53:51 +0000 (UTC) (envelope-from vasanth.raonaik@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 59B198FC17 for ; Tue, 29 May 2012 14:53:51 +0000 (UTC) Received: by werg1 with SMTP id g1so3437078wer.13 for ; Tue, 29 May 2012 07:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GXZAatE0OSWvWI2PbobwGsdgMZiecOHdphvwmAYHUks=; b=kYt5Sdpy93eCzQqg14DVnrcS+ZWvlc/NiONAYJIV9kuM4MT7Rs/fbvdYhPKRAu4OTJ RZJTTJP4C2dmX9FzOzYTxBzlg5KD8785xLhJZHZo6DXmcsbG0soyLQ07ZGIfJcFYHynA QzZIrZ+i3JgmMoSjA1n9lSslNbZghkw7eaLJc4MqzvDIOKbkx+6O+bREOvB42wXOYhwU hJ8d7NZJ/rqZEz8yLaCTQxdc/316HOhgPrBN8bQlHV5G/HnKJelA54FpO1mm6EuV7CK8 G3EKpaYWX59hQrCxmMh/qJE5HTS2JvNrkwN0qWkQeFzGWq4++WZjHHR8yxd+YdA64ZyL 9GFA== MIME-Version: 1.0 Received: by 10.216.212.1 with SMTP id x1mr7871847weo.143.1338303230483; Tue, 29 May 2012 07:53:50 -0700 (PDT) Received: by 10.180.146.37 with HTTP; Tue, 29 May 2012 07:53:50 -0700 (PDT) Date: Tue, 29 May 2012 10:53:50 -0400 Message-ID: From: vasanth rao naik sabavat To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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 14:53:51 -0000 Hi, 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? Thanks, Vasanth