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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 22 Jul 2012 14:58:43 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ming Lei <tom.leiming@...il.com>,
	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>,
	Oliver Neukum <oneukum@...e.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] firmware load: defer request_firmware during early boot
 and resume

On Sat, Jul 21, 2012 at 01:38:52PM -0700, Linus Torvalds wrote:
> > Looks it is not difficult to cache firmware data by kernel, for example, just
> > call the
> >
> >            cache_firmware(fw_name)
> >
> > for each device which need firmware before suspending,
> > then call the below to uncache firmware after resume:
> >
> >            uncache_firmware(fw_name)
> 
> Exactly. But we should make it automatic, and we should only do it if
> the device is actually *active*. If nobody is using the device over
> the suspend-resume event, the firmware shouldn't be loaded in the
> first place, and resume obviously shouldn't need to re-load it.
> Wouldn't it be nice if something like the PCI layer (or the USB layer)
> just knew to do the rigth thing for the device on its own?
> 
> I would also suggest that the firmware caching have some internal
> timeout, so that for the (fairly common) case where a suspend/resume
> event might look like a unplug/replug event, the caching would
> actually still remember the firmware despite the fact that it looked
> (for a short while) like the device went away.
> 
> So *this* is where I think we could improve on the generic code. Make
> it really easy for devices to do the right thing. Make sure that
> firmware caches work, even if it looks like devices disappeared
> momentarily. Maybe add a few callbacks from generic code to say "you
> can load your firmware now, because the system is up".

Question: is there any other reason

  [besides maybe embedded people who care about each single Kb of memory
   on the system]

why we don't make this cache/uncache firmware thing *implicit*? That is,
load it once at driver open time and keep it in memory during the whole
driver's lifetime. And this all taken care of by the driver core, btw.

This way you have the const void *firmware always there and can
apply it whenever you feel like it, you obviate all the problems of
request_firmware and it needing userspace and simpify the whole firmware
handling and delays stuff immensely.

You'd only waste just a couple of Kbs per system but what does memory
cost nowadays...

Oh, we'd probably need to be able to jettison the old firmware and
update to a new one but this can be done at convenient moments when the
system is up and we have userspace to do so.

Hmm...

-- 
Regards/Gruss,
    Boris.
--
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/