linux-kernel - Re: [PATCH v4] PM: Support aborting sleep during filesystem sync

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJZ5v0h31=e8QfodNioB77Wc3xwRipea3mW9LeEibJSw6L-WuA@mail.gmail.com>
Date: Mon, 13 Oct 2025 20:25:27 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Saravana Kannan <saravanak@...gle.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Samuel Wu <wusamuel@...gle.com>, Len Brown <lenb@...nel.org>, 
	Pavel Machek <pavel@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Danilo Krummrich <dakr@...nel.org>, kernel-team@...roid.com, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] PM: Support aborting sleep during filesystem sync

On Mon, Oct 13, 2025 at 8:13 PM Saravana Kannan <saravanak@...gle.com> wrote:
>
> On Mon, Oct 13, 2025 at 11:02 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Thu, Oct 2, 2025 at 12:13 AM Saravana Kannan <saravanak@...gle.com> wrote:
> > >
> > > On Wed, Oct 1, 2025 at 11:22 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > >
> > > > On Wed, Oct 1, 2025 at 12:37 AM Samuel Wu <wusamuel@...gle.com> wrote:
> > > > >
> > > > > On Tue, Sep 30, 2025 at 11:51 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, Sep 30, 2025 at 8:30 PM Samuel Wu <wusamuel@...gle.com> wrote:
> > > > > > >
> > > > > > > Hi Rafael,
> > > > > > >
> > > > > > > Just a friendly ping on this patch. Please let me know if there's any
> > > > > > > feedback or if you'd like me to make any changes.
> > > > > >
> > > > > > Have you seen https://lore.kernel.org/all/20250909065836.32534-1-tuhaowen@uniontech.com/
> > > > > > ?
> > > > > >
> > > > > > If so, what do you think about it?
> > > > >
> > > > > I was following this chain
> > > > > (https://lore.kernel.org/all/20250908024655.14636-1-tuhaowen@uniontech.com/),
> > > > > where there is some ongoing discussion on converging the solution.
> > > > >
> > > > > Our changes aren't mutually exclusive, and tuhaowen can build changes
> > > > > on top of ours, even indicating:
> > > > > > I'm happy to work on this as a follow-up patch series after your changes land, or we could explore a unified solution that handles both scenarios.
> > > >
> > > > That's fair.
> > > >
> > > > > These patchsets don't negate each other, so could we decouple these
> > > > > two patchsets since they address different issues?
> > > >
> > > > Well, I'm not sure if they are really different.  After all, this is
> > > > all about avoiding having to wait on an excessively long filesystem
> > > > sync during suspend.
> > >
> > > No, it's different. We don't mind a long filesystem sync if we don't
> > > have a need to abort a suspend. If it takes 25 seconds to sync the
> > > filesystem but there's no need to abort it, that's totally fine. So,
> > > this patch is just about allowing abort to happen without waiting for
> > > file system sync to finish.
> >
> > OK, thanks for clarification.
> >
> > > The other patch's requirement is to always abort if suspend takes 25
> > > seconds (or whatever the timeout is). IIRC, in his case, it's because
> > > of a bad disk or say a USB disk getting unplugged. I'm not convinced a
> > > suspend timeout is the right thing to do, but I'm not going to nack
> > > it. But to implement his requirement, he can put a patch on top of
> > > ours where he sets a timer and then aborts suspends if it fires.
> > >
> > > > I'm also not sure why it is being pursued to be honest.  Is setting
> > > > /sys/power/sync_on_suspend to 0 not regarded as a viable option?
> > >
> > > We do want to sync on every suspend. So, we don't want to turn it off
> > > completely.
> >
> > I wonder why though.
> >
> > If suspend/resume works reliably, syncing filesystems on every attempt
> > to suspend the system isn't particularly useful AFAICS.
>
> A lot of people's entire digital life is on their phone. Even if
> there's just 1% crash, when you look at that across billions of users
> it adds up to serious impact.
>
> Also, there are classes of devices where we do disable sync on suspend
> (I can't share specifics). So, this is not an arbitrary stance. For
> phones, we want to sync on suspend.
>
> Also, your question could be posed equally to laptops too. If suspend
> is reliable, then the laptop can always wake up at 3% battery, sync,
> and then shutdown. But that's a leap of faith none of us want to make.
> So, as long as we support sync on suspend, I think it makes sense to
> allow suspend aborts to happen more gracefully.

The sync on suspend may not prevent damage from happening when suspend
or resume crashes though.

On laptops it is mostly a mitigation for letting the battery run dry
while suspended due to the lack of safety there on the majority of
systems, but on phones that shouldn't be a problem AFAICS.