Re: 5.2-BETA dsp.c duplicate lock

On Dec 01, Maxime Henrion wrote:
> 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.

	Funny, I was thinking the exact same thing the other day.  I'm
%100 for this idea.

> 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.

	I believe that your patch should fix the problem.  In general
I see one of three strategies,

1)	Your patch,
2)	create a new snd_mtxcreate_chan for channels that sets the
flags DUP_OK.
3)	Fix locking to never hold duplicates.  First glance suggests
that would be contained in dsp.c, the ioctl handler is the real
problem and seems inconsistent with itself in regards to locking.
Ugh.

> 
> > 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. :-)

	I hear you.  The fact is, currently there are no experienced
sound people.

	Anyway, my order of preference is #2, #3, #1.  Since #1
exists, I don't mind it being committed until we really understand
what's going on.  I will work on #3 tonight and maybe fallback to #2.

	Cheers,
	--Mat


-- 
		Applicants must also have extensive knowledge of UNIX,
	although they should have sufficiently good programming
	taste to not consider this an achievement.
			- MIT AI Lab job ad in the /Boston Globe/