linux-kernel - Re: Root filesystem read access for firmware load during hibernation image writing

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: <413b1e99-8cfe-4018-9ef3-2f3e21806bad@maciej.szmigiero.name>
Date: Sat, 5 Oct 2024 15:16:27 +0200
From: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>,
 Pavel Machek <pavel@....cz>
Cc: linux-pm <linux-pm@...r.kernel.org>, linux-kernel@...r.kernel.org,
 Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
 David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
 Luis Chamberlain <mcgrof@...nel.org>, Russ Weight <russ.weight@...ux.dev>,
 Danilo Krummrich <dakr@...hat.com>
Subject: Re: Root filesystem read access for firmware load during hibernation
 image writing

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.

CC: request_firmware() maintainers

Thanks,
Maciej

On 28.08.2024 21:08, Maciej S. Szmigiero wrote:
> Hi,
> 
> I have a quick question about hibernation "image writing" state - is
> (root) filesystem *read* access supposed to be working normally at that point?
> 
> Specifically, I know that devices are resumed (PMSG_THAW) after preparing
> the hibernation image.
> 
> In my case, a USB device (RTL8821CU) gets reset at that stage due to
> commit 04b8c8143d46 ("btusb: fix Realtek suspend/resume") and so it tries
> to request_firmware() from the root filesystem after that thaw/reset,
> when the hibernation image is being written.
> 
> It usually succeeds, however often it deadlocks somewhere in Btrfs code
> resulting in the system failing to power off after writing the hibernate
> image:
> power_off() calls dpm_suspend_start(), which calls dpm_prepare(), which
> waits for device probe to finish.
> 
> And device probe is stuck forever trying to load that USB stick firmware
> from the filesystem - so in the end the system never powers off during
> (after) hibernation.
> 
> That's why I wonder whether this firmware load is supposed to work correctly
> during that hibernation state and so the system may be hitting some kind of
> a swsusp/btrfs/block layer race condition.
> 
> Or, alternatively, maybe  reading files is not supported at this point and
> so this is really a btrtl/rtw88 bug?
> 
> CCing Btrfs people in case it is some known Btrfs issue.
> 
> Btw, this is on upstream kernel 6.10.6 and the "Show Blocked State" trace
> during that failed power off is attached below.