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.