Re: via82cxxx_audio locking problems

[Jeff Garzik]

On Thu, 20 Sep 2001, Thomas Sailer wrote:

> This applies to version 1.1.5 as well as the version in
> linux-2.4.10-pre12 and linux-2.4.9-ac12.
> 
> 1) There is one semaphore (syscall_sem) that is held during
>    calls from userspace. It is even kept while going to sleep
>    during read and write syscalls. This locks out other users,
>    eg. mixers, for a potentially very long time, seconds are
>    common but it may almost be arbitrarily long. Try changing
>    the volume with eg. gmix while playing something with eg. xmms.
> 
>    Dropping and reacquiring syscall_sem around interruptible_sleep_on
>    in via_dsp_do_read, via_dsp_do_write and via_dsp_drain_playback
>    should solve the problem. Does anyone see a problem with this?

Is there a possibility of do_read being re-entered during that window?
I agree its a problem but the solution sounds racy?

> 2) When some kind of error happens during read or write after
>    some samples have already been dequeued and copied to the user
>    buffer, the number of copied bytes should be returned instead
>    of the error code, to avoid loosing samples.

Very true

> 3) The use of interruptible_sleep_on results in a small race where
>    wake_ups may be lost. Unlikely to hit though.
> 
> 4) The down_trylock and returning -EAGAIN in via_down_syscall looks
>    questionable, EAGAIN with O_NONBLOCK normally means I/O has to
>    be completed first, not that there is contention on some internal
>    synchronisation primitive.

I disagree; I think the idea at aleast is correct:  if contention
exists, it implies that I/O needs to be completed.

> Jeff, do you object any of this? Would you accept a patch to ameliorate
> the situation? Or would you like to fix this yourself?

A fix patch would definitely be accepted...

	Jeff