Re: pcm(4) related panic

On 25 Nov, Don Lewis wrote:
> 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 _at_ \   
>>>         /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.

Following up to myself ...

It might be safe to drop the mutex for the uiomove() call if the code
set flags to enforce a limit of one reader and one writer at a time to
keep the code from being re-entered.  The buffer pointer manipulations
in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
protected by the mutex.  If this can be made to work, it would probably
be preferable to wiring the buffer.  It would have a lot less CPU
overhead, and would work better with large buffers, which could still be
allowed to page normally.