Locking/mutex for snd_pcm_update_hw_ptr0() call

Locking/mutex for snd_pcm_update_hw_ptr0() call

[Alan Young]

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.

Re: Locking/mutex for snd_pcm_update_hw_ptr0() call

[Clemens Ladisch]

Alan Young wrote:
> It is possible that the DMA interrupt handler could call
> snd_pcm_update_hw_ptr0() while it is part way through a call
> from snd_pcm_status(), or vice versa?

The *lock_irq* functions disable interrupts on the current CPU.


Regards,
Clemens

Re: Locking/mutex for snd_pcm_update_hw_ptr0() call

[Alan Young]

On 07/11/16 14:15, Clemens Ladisch wrote:
> Alan Young wrote:
>> It is possible that the DMA interrupt handler could call
>> snd_pcm_update_hw_ptr0() while it is part way through a call
>> from snd_pcm_status(), or vice versa?
> The *lock_irq* functions disable interrupts on the current CPU.
>
>

But only on the current CPU? So that would imply that multiple threads 
could execute snd_pcm_update_hw_ptr0() simultaneously on multi-CPU systems.

Even on a single-CPU system, I presume that the interrupt handler cannot 
be pre-empted by a user-space call such as snd_pcm_status(). Is that 
correct?

Alan.

Re: Locking/mutex for snd_pcm_update_hw_ptr0() call

[Clemens Ladisch]

Alan Young wrote:
> On 07/11/16 14:15, Clemens Ladisch wrote:
>> Alan Young wrote:
>>> It is possible that the DMA interrupt handler could call
>>> snd_pcm_update_hw_ptr0() while it is part way through a call
>>> from snd_pcm_status(), or vice versa?
>>
>> The *lock_irq* functions disable interrupts on the current CPU.
>
> But only on the current CPU? So that would imply that multiple threads
> could execute snd_pcm_update_hw_ptr0() simultaneously on multi-CPU
> systems.

That's what the lock is for.

> I presume that the interrupt handler cannot be pre-empted by a user-
> space call such as snd_pcm_status().

During execution of an interrupt handler, interrupts also are disabled.


Regards,
Clemens