Date: Tue, 2 Dec 2003 00:02:59 +0100 From: Maxime Henrion <mux@freebsd.org> To: Mathew Kanner <mat@cnd.mcgill.ca> Cc: freebsd-current@freebsd.org Subject: Re: 5.2-BETA dsp.c duplicate lock Message-ID: <20031201230259.GL8404@elvis.mu.org> In-Reply-To: <20031201193837.GD49341@cnd.mcgill.ca> References: <bq68t8$c8n$2@sea.gmane.org> <bqfgsc$qmu$1@sea.gmane.org> <20031201142022.GK8404@elvis.mu.org> <20031201193837.GD49341@cnd.mcgill.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031201230259.GL8404>