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@xxxxxxx> 发送时间: 2023年6月26日 2:13 收件人: YE Chengfeng <cyeaa@xxxxxxxxxxxxxx> 抄送: perex@xxxxxxxx <perex@xxxxxxxx>; tiwai@xxxxxxxx <tiwai@xxxxxxxx>; yunjunlee@xxxxxxxxxxxx <yunjunlee@xxxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx <alsa-devel@xxxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx> 主题: 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
