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: <CAJZ5v0hbtHxFo_z2fp9DMRDi75k6QL-kcDHD+o8zabub1YdCKg@mail.gmail.com>
Date: Mon, 13 Oct 2025 20:02:37 +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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ