Messages in this thread | | | Date | Wed, 19 Jul 2023 08:18:17 -0700 | From | Bjorn Andersson <> | Subject | Re: [PATCH] mfd: qcom-pm8xxx: Fix potential deadlock on &chip->pm_irq_lock |
| |
On Wed, Jun 28, 2023 at 07:28:40AM +0000, Chengfeng Ye wrote: > As &chip->pm_irq_lock is acquired by pm8xxx_irq_handler() under irq > context, other process context code should disable irq before acquiring > the lock. > > I think .irq_set_type and .irq_get_irqchip_state callbacks should be
You are correct, so please drop "I think", and change "should be" to "are generally".
> executed from process context without irq disabled by default. Thus the > same lock acquision should disable irq. > > Possible deadlock scenario > pm8xxx_irq_set_type() > -> pm8xxx_config_irq() > -> spin_lock(&chip->pm_irq_lock) > <irq interrupt> > -> pm8xxx_irq_handler() > -> pm8xxx_irq_master_handler() > -> pm8xxx_irq_block_handler() > -> pm8xxx_read_block_irq() > -> spin_lock(&chip->pm_irq_lock) (deadlock here) > > This flaw was found using an experimental static analysis tool we are > developing for irq-related deadlock. > > The tentative patch fix the potential deadlock by spin_lock_irqsave().
I don't think this is a "tentative patch fix", it is the patch to fix the issue. I think you can omit this line, because you already described your problem, and the solution above.
> > Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Regards, Bjorn
| |