linux-kernel - Re: [RFC] firmware load: defer request_firmware during early boot and resume

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 20 Jul 2012 23:53:02 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] firmware load: defer request_firmware during early boot and resume

On Fri, Jul 20, 2012 at 9:54 PM, Oliver Neukum <oneukum@...e.de> wrote:

>
> The approach seems to me to be less comprehensive than
> it ought to be. If you defer, why not the whole probe()?

Because for other failures, we don't know when the conditions
for them can be satisfied. For example, we don't know when the
memory allocation can be met for one previous allocation failure.

IMO, at least the approach provides one simple way to solve the
firmware loading problem during. early boot or resume

> Deferring only the upoad of the firmware complicates
> error handling.

Looks there is no special requirement for the error handling of
request_firmware, just like other failures' handling, undo things
which has been done, isn't there?

Thanks,
-- 
Ming Lei
--
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/