linux-kernel - Re: Dead lock with clock global prepare_lock mutex and device's power.runtime

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: <87pldsd1tq.fsf@bootlin.com>
Date: Tue, 22 Jul 2025 11:14:41 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Chen-Yu Tsai <wens@...nel.org>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>,  Peng Fan
 <peng.fan@....nxp.com>,  Carlos Song <carlos.song@....com>,  Ulf Hansson
 <ulf.hansson@...aro.org>,  Stephen Boyd <sboyd@...nel.org>,
  "imx@...ts.linux.dev" <imx@...ts.linux.dev>,  "rafael@...nel.org"
 <rafael@...nel.org>,  "mturquette@...libre.com" <mturquette@...libre.com>,
  Frank Li <frank.li@....com>,  "linux-i2c@...r.kernel.org"
 <linux-i2c@...r.kernel.org>,  "dakr@...nel.org" <dakr@...nel.org>,
  "festevam@...il.com" <festevam@...il.com>,  "linux-clk@...r.kernel.org"
 <linux-clk@...r.kernel.org>,  "pavel@...nel.org" <pavel@...nel.org>,
  Bough Chen <haibo.chen@....com>,  "len.brown@...el.com"
 <len.brown@...el.com>,  Andi Shyti <andi.shyti@...nel.org>,
  "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
  "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
  "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,  Aisheng Dong
 <aisheng.dong@....com>,  Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
  "kernel@...gutronix.de" <kernel@...gutronix.de>,  "shawnguo@...nel.org"
 <shawnguo@...nel.org>,  Jun Li <jun.li@....com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: Dead lock with clock global prepare_lock mutex and device's
 power.runtime_status

Hello,

Thanks Chen-Yu for the heads up!

On 08/07/2025 at 01:28:08 +08, Chen-Yu Tsai <wens@...nel.org> wrote:

> Hi,
>
> On Mon, Jul 7, 2025 at 7:05 PM Marc Kleine-Budde <mkl@...gutronix.de> wrote:
>>
>> On 07.07.2025 18:58:16, Peng Fan wrote:
>> > On Tue, Jul 01, 2025 at 03:16:08AM +0000, Carlos Song wrote:
>> > >Hi, All:
>> > >
>> > >We met the dead lock issue recently and think it should be common issue and not sure how to fix it.
>> > >
>> > >We use gpio-gate-clock clock provider (drivers/clk/clk-gpio.c), gpio is one of i2c gpio expander (drivers/gpio/gpio-pcf857x.c). Our i2c driver enable run time pm (drivers/i2c/busses/i2c-imx-lpi2c.c [1]). System random blocked when at reboot.
>> > >
>> > >The dead lock happen as below call stacks
>> > >
>> > >Task 117                                                Task 120
>> > >
>> > >schedule()
>> > >clk_prepare_lock()--> wait prepare_lock(mutex_lock)     schedule() wait for power.runtime_status exit RPM_SUSPENDING
>> > >                           ^^^^ A                       ^^^^ B
>> > >clk_bulk_unprepare()                                    rpm_resume()
>> > >lpi2c_runtime_suspend()                                 pm_runtime_resume_and_get()
>> > >...                                                     lpi2c_imx_xfer()
>> > >                                                        ...
>> > >rpm_suspend() set RPM_SUSPENDING                        pcf857x_set();
>> > >                           ^^^^ B                       ...
>> > >                                                        clk_prepare_lock() --> hold prepare_lock
>> > >                                                        ^^^^ A
>> > >                                                        ...
>> > >
>> >
>> > This is a common issue that clk use a big prepare lock which is easy
>> > to trigger dead lock with runtime pm. I recalled that pengutronix raised
>> > this, but could not find the information.
>>
>> Alexander Stein stumbled over this issue some time ago:
>>
>> | https://lore.kernel.org/all/20230421-kinfolk-glancing-e185fd9c47b4-mkl@pengutronix.de/
>>
>> I encountered it too, while trying to add a clock provider driver for a
>> SPI attached CAN controller which uses runtime pm.
>
> Miquel from Bootlin posted a more formal description of the problem and
> some possible solutions last year [1].
>
> [1] https://lore.kernel.org/all/20240527181928.4fc6b5f0@xps-13/

I also sent an RFC in April:
https://lore.kernel.org/all/20250326-cross-lock-dep-v1-0-3199e49e8652@bootlin.com/

I haven't got the energy yet to process the interesting feedback from
Rafael and Stephen. But getting a broader audience and maybe more
feedback will certainly help!

Thanks,
Miquèl