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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAGETcx_XFUg7V5KEGF+eqDtmhbUoufs8xARhaB0KJeh7Lzaj0w@mail.gmail.com>
Date: Mon, 13 Oct 2025 11:12:35 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: 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 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.

Thanks,
Saravana