From owner-freebsd-current Sat Sep 28 13:25:19 2002 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 71DB137B401; Sat, 28 Sep 2002 13:25:18 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1378A43E3B; Sat, 28 Sep 2002 13:25:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0023.cvx22-bradley.dialup.earthlink.net ([209.179.198.23] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17vO9I-0006im-00; Sat, 28 Sep 2002 13:25:13 -0700 Message-ID: <3D960FE4.80E7CB24@mindspring.com> Date: Sat, 28 Sep 2002 13:24:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juli Mallett Cc: Poul-Henning Kamp , Marc Recht , current@FreeBSD.ORG Subject: Re: GEOM panic in current kernel References: <33985.1033238233@critter.freebsd.dk> <3D960745.1224A651@mindspring.com> <20020928130558.A72197@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett wrote: > * De: Terry Lambert [ Data: 2002-09-28 ] > > Poul-Henning Kamp wrote: > > > + bzero(&mymutex, sizeof mymutex); > > > mtx_init(&mymutex, "g_up", MTX_DEF, 0); > > > > > > Too bad mtx_init() doesn't really initialize the mutex, or > > this would not be necessary. 8-(. > > That would break some witness checks, Terry, which check for something very > bad, which shouldn't happen: a mutex actually being initialised twice. The ones in this case are on the stack, which means that they are not going to persist long enough for that to be a problem. For persistent mutexes, this implies that bzero()'ing is a bad thing to do (from a witness perspective), but a good thing to do otherwise. What this all implies to me is that there needs to be a mutex allocation/deallocation mechanism for keeping witness happy, by verifying that the mutex is no longer used at the point that it is freed, so that it's OK to bzero() it on initial allocation (to differentiate initial allocation from reuse). The point comes down to "where do little mutexes come from?". Actually, it seems to me that it should be OK to initialize a mutex multiple times, and only not OK to initialize it if it's in use. In other words, I don't think that the protection you are talking about is protecting against what it;s pretending to. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message