On Tue, 27 Jun 2023 11:56:16 +0200, Chengfeng Ye wrote:
As &chip->mixer_lock is also acquired by the irq snd_sb8dsp_interrupt() which executes under hard-irq context, code executing under process context should disable irq before acquiring the lock, otherwise deadlock could happen if the process context hold the lock then preempt by the interruption.
As the ALSA Driver document described, PCM prepare callbacks are not executed with irq disabled by default, thus the acquiring of &chip->mixer_lock should be irq disabled.
Possible deadlock scenario: snd_sb8_playback_prepare -> spin_lock(&chip->mixer_lock); <irq interrupt> -> snd_sb8dsp_interrupt() -> snd_sb8_capture_trigger() -> spin_lock(&chip->mixer_lock); (deadlock here)
This flaw was found using an experimental static analysis tool we are developing for irq-related deadlock.
The tentative patch fix the potential deadlock by spin_lock_irqsave().
Signed-off-by: Chengfeng Ye dg573847474@gmail.com
I believe it's a false-positive. There is already a call spin_lock_irqsave(&chip->reg_lock, flags); beforehand.
thanks,
Takashi