From owner-freebsd-current@FreeBSD.ORG Mon Dec 1 15:03:00 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 A20E916A4CE for ; Mon, 1 Dec 2003 15:03:00 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0EEA43F75 for ; Mon, 1 Dec 2003 15:02:59 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id A1B482ED435; Mon, 1 Dec 2003 15:02:59 -0800 (PST) Date: Tue, 2 Dec 2003 00:02:59 +0100 From: Maxime Henrion To: Mathew Kanner Message-ID: <20031201230259.GL8404@elvis.mu.org> References: <20031201142022.GK8404@elvis.mu.org> <20031201193837.GD49341@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201193837.GD49341@cnd.mcgill.ca> User-Agent: Mutt/1.4.1i cc: Jesse Guardiani cc: freebsd-current@freebsd.org Subject: Re: 5.2-BETA dsp.c duplicate lock 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: Mon, 01 Dec 2003 23:03:00 -0000 Mathew Kanner wrote: [patch ripped] > > Maxime, > I think it would be better to isolate the changes (DUP_OK flag > and lock creation) to just the channel code, no need to touch every > driver. Yes, but to do this I'd need either to make the channel code use mtx_init() directly, which would defeat the purpose of the USING_MUTEX define, or to completely unifdef -U it. Since I had no idea if this code was actually used or not, I went the safe way and just changed the snd_mtxcreate() wrapper interface to accept mutex options. For what it's worth, there is at least one direct invokation of mtx_init() in the sound drivers, so it seems this define is actually already broken. This needs to be sorted out before committing this patch if we need to, but for now, I just wanted to see if using MTX_DUPOK solved the problem or not. > Also, if this is the right direction, we should back out the > commit I did that re-ordered code that prevented duplicate channel > locks (obviously it wasn't completen) channel. If the code is not supposed to acquire several channel locks at once, then yes, it's not the right direction to go. As I said in my previous mail, and that's why I wanted the advice of you sound guys, in that case it's just a workaround. :-) Cheers, Maxime