linux-kernel - Re: [PATCH v2] misc: bcm_vk: Fix potential deadlock on &vk->ctx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAAo+4rWgg7ZCTt1K=sdTb6Nt1unKEP5e5rWMknS3=cebXP818w@mail.gmail.com>
Date:   Fri, 30 Jun 2023 02:33:38 +0800
From:   Chengfeng Ye <dg573847474@...il.com>
To:     Arnd Bergmann <arnd@...db.de>, scott.branden@...adcom.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     bcm-kernel-feedback-list@...adcom.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] misc: bcm_vk: Fix potential deadlock on &vk->ctx_lock

> 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.

Thanks for the suggestion, new patch is sent with a delayed workqueue.

Best Regards,
Chengfeng

Arnd Bergmann <arnd@...db.de> 于2023年6月28日周三 19:56写道：
>
> 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