linux-kernel - Re: Hang while loading firmware when going into suspend

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] [day] [month] [year] [list]

Message-ID: <CAMLZHHToiBUw-pTm6R=EZ5mHK5B55Y6arqdqDn-tzLicEdwMjA@mail.gmail.com>
Date:	Mon, 14 May 2012 16:41:07 -0600
From:	Daniel Drake <dsd@...top.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Hang while loading firmware when going into suspend

Hi,

On Thu, Apr 26, 2012 at 1:15 PM, Daniel Drake <dsd@...top.org> wrote:
> I can easily reproduce a hang related to loading firmware
> (asynchronously) while going into suspend.
>
> This is running on kernel 3.3.3.
>
> I run:
>
> echo mem > /sys/power/state; echo mem > /sys/power/state
>
> i.e. I tell the system to suspend, and when I wake it up it will go
> very quickly into suspend again.
>
> After waking up, it will start to re-detect the libertas SDIO wifi
> card which was completely powered down during suspend.
> This triggers a firmware loading sequence.
> However, the system then immediately goes into suspend, and at this
> point the system becomes unhappy.

We're still suffering from this issue.

As far as I can see there are 2 items in question:

1. If a firmware load is in-progress as the system goes into suspend,
the relevant userspace processes get frozen and then we have to wait
for the timeout - the firmware loader in the kernel doesn't do
anything special on this important event.

2. There are no safety traps for if a new firmware load request
happens while the system is being suspended with userspace processes
already frozen. Then we have to wait for another timeout.

Do you have any suggested approaches to solve this?

I'm wondering if this is appropriate: firmware_class should add a
pm_notifier so that it is notified when the system is going into
suspend. It would set an internal flag noting that the system is
suspending, and then it can call fw_load_abort() on any active
firmware loads, making them fail immediately.
_request_firmware() would check the internal flag when it is called,
immediately returning failure -ENODATA (?) when the system is going
into suspend.

Does this sound reasonable or should I be looking for another approach?

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/