From owner-freebsd-current@FreeBSD.ORG  Tue Jun 24 20:45:07 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 194E037B401
	for <current@FreeBSD.org>; Tue, 24 Jun 2003 20:45:07 -0700 (PDT)
Received: from mail26d.sbc-webhosting.com (mail26d.sbc-webhosting.com
	[216.173.237.167])
	by mx1.FreeBSD.org (Postfix) with SMTP id 5944743FD7
	for <current@FreeBSD.org>; Tue, 24 Jun 2003 20:45:06 -0700 (PDT)
	(envelope-from alc@imimic.com)
Received: from www.imimic.com (64.143.12.21)0805642693;
	Tue, 24 Jun 2003 23:44:53 -0400 (EDT)
Sender: alc@FreeBSD.ORG
Message-ID: <3EF91AB7.3D92D34F@imimic.com>
Date: Tue, 24 Jun 2003 22:44:55 -0500
From: "Alan L. Cox" <alc@imimic.com>
Organization: iMimic Networking, Inc.
X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Gallatin <gallatin@cs.duke.edu>
References: <20030624004308.GA17534@rot13.obsecurity.org>
	<16120.51322.899065.483700@grasshopper.cs.duke.edu>
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
cc: current@FreeBSD.org
Subject: Re: LOR in VM (with backtrace)
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, 25 Jun 2003 03:45:07 -0000

Andrew Gallatin wrote:
> 
> Alan L. Cox writes:
>  > Thanks for letting me know.  This is another false positive: Witness
>  > can't distinguish the lock on the object being destroyed from the lock
>  > on the object used by UMA because their labels are the same.  They will
>  > never, however, be the same object.  So, deadlock isn't a risk.
> 
> In a closed source driver I maintain, I had to resort to passing a
> string containing the meaningful name concatonated with some unique info
> to mtx_init().
> 
> It seems like witness could just concat the address of the mutex along
> with the strings passed to mtx_init() so as to make sure things were
> unique..
> 

I'm not sure that witness could handle the 30,000 to 200,000 distinct
mutex labels that would result from doing this for every vm object.

Regards,
Alan