Messages in this thread | | | Date | Wed, 28 Jun 2023 13:56:29 +0200 | From | "Arnd Bergmann" <> | Subject | Re: [PATCH v2] misc: bcm_vk: Fix potential deadlock on &vk->ctx_lock |
| |
On Wed, Jun 28, 2023, at 13:29, Chengfeng Ye wrote: > As &vk->ctx_lock is acquired by timer bcm_vk_hb_poll() under softirq > context, other process context code should disable irq or bottom-half > before acquire the same lock, otherwise deadlock could happen if the > timer preempt the execution while the lock is held in process context > on the same CPU. > > Possible deadlock scenario > bcm_vk_open() > -> bcm_vk_get_ctx() > -> spin_lock(&vk->ctx_lock) > <timer iterrupt> > -> bcm_vk_hb_poll() > -> bcm_vk_blk_drv_access() > -> spin_lock_irqsave(&vk->ctx_lock, flags) (deadlock here) > > This flaw was found using an experimental static analysis tool we are > developing for irq-related deadlock, which reported the following > warning when analyzing the linux kernel 6.4-rc7 release.
The timer function does not seem to be performance critical at all, it might be nicer to just move it into process context using a delayed workqueue instead of a timer.
Arnd
| |