From: Luis Chamberlain <mcgrof@kernel.org>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
"Darrick J. Wong" <djwong@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
linux-pm <linux-pm@vger.kernel.org>,
linux-kernel@vger.kernel.org, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, Russ Weight <russ.weight@linux.dev>,
Danilo Krummrich <dakr@redhat.com>
Subject: Re: Root filesystem read access for firmware load during hibernation image writing
Date: Fri, 11 Oct 2024 16:11:49 -0700 [thread overview]
Message-ID: <ZwmwtZivKP8UDx1V@bombadil.infradead.org> (raw)
In-Reply-To: <413b1e99-8cfe-4018-9ef3-2f3e21806bad@maciej.szmigiero.name>
On Sat, Oct 05, 2024 at 03:16:27PM +0200, Maciej S. Szmigiero wrote:
> The issue below still happens on kernel version 6.11.1.
>
> Created a kernel bugzilla entry for it:
> https://bugzilla.kernel.org/show_bug.cgi?id=219353
>
> It would be nice to at least know whether the filesystem read access supposed is
> to be working normally at PMSG_THAW hibernation stage to assign the issue accordingly.
No, there are races possible if you trigger IO to a fs before a suspend
is going on. If you have *more* IO ongoing, then you are likely to stall
suspend and not be able to recover.
> CC: request_firmware() maintainers
If IO is ongoing suspend is broken today because of the kthread freezer
which puts kthreads which should sleep idle, but if IO is ongoing we
can stall. This is work which we've been working to remove for years and
after its removal we can gracefully freeze filesystems [0] [1]
properly on suspend.
Other than that, obviously upon resume we want firmware to be present,
and to prevent races on resume we have a firmware cache. So on suspend
we cache used firmware so its available in cache on resume. See
device_cache_fw_images().
So.. we just now gotta respin the latest effort. I had stopped because
I know Darrick had some changes which he needed to get in sooner but
since this is low hanging fruit I never got around to it. So someone
just needs to respin the series.
[0] https://lwn.net/Articles/752588/
[1] https://lwn.net/Articles/935602/
Luis
next prev parent reply other threads:[~2024-10-11 23:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 19:08 Root filesystem read access for firmware load during hibernation image writing Maciej S. Szmigiero
2024-10-05 13:16 ` Maciej S. Szmigiero
2024-10-11 23:11 ` Luis Chamberlain [this message]
2024-10-11 23:39 ` Darrick J. Wong
2024-10-11 23:44 ` Luis Chamberlain
2024-10-05 17:40 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZwmwtZivKP8UDx1V@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=clm@fb.com \
--cc=dakr@redhat.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=len.brown@intel.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).