Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230628112958.45374-1-dg573847474@gmail.com> <2a1220fc-777c-4611-9f75-3a8e07a04850@app.fastmail.com>
In-Reply-To: <2a1220fc-777c-4611-9f75-3a8e07a04850@app.fastmail.com>
From:   Chengfeng Ye <dg573847474@gmail.com>
Date:   Fri, 30 Jun 2023 02:33:38 +0800
Message-ID: <CAAo+4rWgg7ZCTt1K=sdTb6Nt1unKEP5e5rWMknS3=cebXP818w@mail.gmail.com>
Subject: Re: [PATCH v2] misc: bcm_vk: Fix potential deadlock on &vk->ctx_lock
To:     Arnd Bergmann <arnd@arndb.de>, scott.branden@broadcom.com,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> 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@arndb.de> =E4=BA=8E2023=E5=B9=B46=E6=9C=8828=E6=97=A5=
=E5=91=A8=E4=B8=89 19:56=E5=86=99=E9=81=93=EF=BC=9A
>
> 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