Locking/mutex for snd_pcm_update_hw_ptr0() call

[Alan Young <Alan.Young@IEE.org>]

As far as I can see, snd_pcm_update_hw_ptr0() is a critical section of 
code that is protected by some form of mutex in all its call paths:

     snd_pcm_period_elapsed() - snd_pcm_stream_lock_irqsave()

     snd_pcm_update_hw_ptr()

         snd_pcm_lib_ioctl_reset() - snd_pcm_stream_lock_irqsave()

         snd_pcm_lib_write1() - snd_pcm_stream_lock_irq()

         snd_pcm_lib_read1() - snd_pcm_stream_lock_irq()

         snd_pcm_status() - snd_pcm_stream_lock_irq()

         snd_pcm_do_pause - I think via the locking in snd_pcm_action()

         snd_pcm_playback_rewind() - snd_pcm_stream_lock_irq()

         snd_pcm_capture_rewind() - snd_pcm_stream_lock_irq()

         snd_pcm_playback_forward() - snd_pcm_stream_lock_irq()

         snd_pcm_capture_forward() - snd_pcm_stream_lock_irq()

         snd_pcm_hwsync() - snd_pcm_stream_lock_irq()

         snd_pcm_delay() - snd_pcm_stream_lock_irq()



However, I am not familiar with how kernel locking mechanisms work. It 
is possible that the DMA interrupt handler (snd_pcm_period_elapsed()), 
could call snd_pcm_update_hw_ptr0() while it is part way through a call 
from snd_pcm_status(), or vice versa?

Alan.