pcm(4) related panic

[Don Lewis]

On 25 Nov, Artur Poplawski wrote:
> Artur Poplawski <artur at szuruburu.neostrada.pl> wrote:
> 
>> Hello,                                                                          
>>                                                                                 
>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
>> like this:

>> Sleeping on "swread" with the following non-sleepable locks held:
>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
>>         /usr/src/sys/dev/sound/pcm/dsp.c:146

This enables the panic.

>> panic: sleeping thread (pid 583) owns a non-sleepable lock

Then the panic happens when another thread tries to grab the mutex.


The problem is that the pcm code attempts to hold a mutex across a call
to uiomove(), which can sleep if the userland buffer that it is trying
to access is paged out.  Either the buffer has to be pre-wired before
calling getchns(), or the mutex has to be dropped around the call to
uiomove().  The amount of memory to be wired should be limited to
'sz' as calculated by chn_read() and chn_write(), which complicates the
logic.  Dropping the mutex probably has other issues.