From owner-freebsd-current@FreeBSD.ORG Thu Jun 5 04:11:19 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 43E2437B401; Thu, 5 Jun 2003 04:11:19 -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 02E5143FB1; Thu, 5 Jun 2003 04:11:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmr7.dialup.mindspring.com ([165.247.219.103] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19NseI-0002Sg-00; Thu, 05 Jun 2003 04:11:16 -0700 Message-ID: <3EDF250C.F79876F7@mindspring.com> Date: Thu, 05 Jun 2003 04:10:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson References: <20030604021752.Y69975-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e20d29f0969304a7b4325698abc142ad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Bryan Liesner cc: current@freebsd.org 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: Thu, 05 Jun 2003 11:11:19 -0000 Jeff Roberson wrote: > On Tue, 3 Jun 2003, Terry Lambert wrote: > > 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? > > This is no longer the case with the latest revision. Apparently the > panics in cam continue even after the proc lock issues were fixed. As I said: I still think there is a lost serialization here that's at the root of the problem. I can't really dedicate the equipment I have here to reproducing the issue at this time, or I'd track down the race I think may be happening. -- Terry