From owner-freebsd-current@FreeBSD.ORG Tue Jun 3 22:57:13 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C312537B401; Tue, 3 Jun 2003 22:57:13 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 483C443F85; Tue, 3 Jun 2003 22:57:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk3b.dialup.mindspring.com ([165.247.208.107] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19NRGq-0007PJ-00; Tue, 03 Jun 2003 22:57:13 -0700 Message-ID: <3EDD89F0.C3FED9CE@mindspring.com> Date: Tue, 03 Jun 2003 22:56:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Long References: <20030602230746.U69975-100000@mail.chesapeake.net> <3EDCCB27.5020707@freebsd.org><3EDD04CF.80101@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e88769dd5a6643929189454c7e1c75cd548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: Bryan Liesner cc: current@freebsd.org cc: Jeff Roberson Subject: Re: umtx/libthr SMP fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 05:57:14 -0000 Scott Long wrote: > Bryan Liesner wrote: > It's very hard to imagine Jeff's patches causing a problem at the point > that the PR mentions. Have you confirmed the problem in a kernel that > was build in a totally clean environment? The changed code is not protecting a traversal of a proc struct member with a proc lock in two places. What's hard to imagine? Even if it's weren't necessary to protect that FOREACH loop (it's necessary; but even if it weren't...), locking the proc could easily serialize a number of operations through that or other code which could save it from interference. -- Terry