From owner-freebsd-current@FreeBSD.ORG  Tue Jun  3 23:18:33 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 1523A37B404; Tue,  3 Jun 2003 23:18:33 -0700 (PDT)
Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1399B43F75; Tue,  3 Jun 2003 23:18:32 -0700 (PDT)
	(envelope-from jroberson@chesapeake.net)
Received: from localhost (jroberson@localhost)
	by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h546IVw13786;
	Wed, 4 Jun 2003 02:18:31 -0400 (EDT)
	(envelope-from jroberson@chesapeake.net)
Date: Wed, 4 Jun 2003 02:18:31 -0400 (EDT)
From: Jeff Roberson <jroberson@chesapeake.net>
To: Terry Lambert <tlambert2@mindspring.com>
In-Reply-To: <3EDD89F0.C3FED9CE@mindspring.com>
Message-ID: <20030604021752.Y69975-100000@mail.chesapeake.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Bryan Liesner <bleez@verizon.net>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2003 06:18:33 -0000

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.

> 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
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>