These bugs are detected by an experimental static analyzer that I am implementing, and I didn't realize that callbacks are already irq-disabled while doing manually confirmation.
So sorry for bothering you for these false positive reports. Perhaps next time I should mention the bugs are detected statically and be careful of these cases.
Thanks so much, Chengfeng ________________________________ 发件人: Takashi Iwai tiwai@suse.de 发送时间: 2023年6月26日 2:13 收件人: YE Chengfeng cyeaa@connect.ust.hk 抄送: perex@perex.cz perex@perex.cz; tiwai@suse.com tiwai@suse.com; yunjunlee@chromium.org yunjunlee@chromium.org; alsa-devel@alsa-project.org alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org 主题: Re: [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
On Sun, 25 Jun 2023 17:35:48 +0200, YE Chengfeng wrote:
The timer dummy_systimer_callback is executed under softirq context, thus other process context code requiring the same lock should disable interrupt. Otherwise there would be potential deadlock issues when the code executing under process context (i.e., dummy_systimer_pointer, dummy_systimer_start, dummy_systimer_stop) is preempted by the timer while holding the lock.
Deadlock scenario: dummy_systimer_pointer -> spin_lock(&dpcm->lock); <timer interrupt> -> dummy_systimer_callback -> spin_lock_irqsave(&dpcm->lock, flags);
Fix the potential deadlock by using spin_lock_irqsave.
Did you really trigger this deadlock, or is just your hypothesis? I'm asking it because basically the deadlock above shouldn't happen; those are called only via PCM trigger and pointer callbacks, and they are always called inside the PCM stream lock, and already irq-disabled.
thanks,
Takashi