[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jjQgoa8eRyQ-MVQW=FeOEVQP6YTsY7o49LV2wnO=xEDw@mail.gmail.com>
Date: Mon, 17 Nov 2025 17:59:05 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Rose Wu <ya-jou.wu@...iatek.com>
Cc: rafael.j.wysocki@...el.com, linux-pm@...r.kernel.org,
regressions@...ts.linux.dev, saravanak@...gle.com, len.brown@...el.com,
pavel@...nel.org, linux-kernel@...r.kernel.org,
wsd_upstream <wsd_upstream@...iatek.com>, linux-mediatek@...ts.infradead.org,
士顏 邱 <artis.chiu@...iatek.com>,
靖智 高 <Johnny-cc.Kao@...iatek.com>
Subject: Re: [REGRESSION] PM / sleep: Unbalanced suspend/resume on late abort
causes data abort
Hi,
On Mon, Nov 17, 2025 at 10:31 AM Rose Wu <ya-jou.wu@...iatek.com> wrote:
>
> Hi Rafael and All,
>
> I am reporting a regression introduced by the commit
> 443046d1ad66607f324c604b9fbdf11266fa8aad (PM: sleep: Make suspend of
> devices more asynchronous), which can lead to a kernel panic (data
> abort) if a late suspend aborts.
> The commit modifies list handling during suspend. When a device suspend
> aborts at the "late" stage, `dpm_suspended_list` is spliced into
> `dpm_late_early_list`.
> This creates an imbalance. Devices on this list that had not yet
> executed `pm_runtime_disable()` in `device_suspend_late()` are now
> incorrectly subjected to `pm_runtime_enable()` during the subsequent
> `device_resume_early()` sequence.
Ah, obviously.
Does the attached patch (that should apply on top of 6.18-rc6) help?
If this patch doesn't apply to your kernel, making an analogous change
to it should be straightforward enough.
View attachment "pm-sleep-fix-early-resume.patch" of type "text/x-patch" (371 bytes)
Powered by blists - more mailing lists