linux-kernel - [RFC PATCH v1 00/15] firmware loader: introduce cache/uncache firmware

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

Message-Id: <1344052890-31935-1-git-send-email-ming.lei@canonical.com>
Date:	Sat,  4 Aug 2012 12:01:15 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Borislav Petkov <borislav.petkov@....com>,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH v1 00/15] firmware loader: introduce cache/uncache firmware

Hi,

In [1][2], the problem below has been discussed for some time:

        device's firmware may be lost during suspend/resume
        cycle because device might be unplugged and plugged again
        or device experiences system power loss during the period.
        But in resume path, system is still not ready(process
        frozen, rootfs not usable, ...) to complete loading firmware
        from user space for devices.

The conclusion is that caching firmware during suspend/resume cycle
is capable of solving the problem.

This patchset implements cache/uncache firmware mechanism,
and apply the mechnism to cache device's firmware in kernel memory
space automatically during suspend/resume cyclye, so device can
load its firmware easily in its resume path. When resume is completed
and system is ready, the cached firmware will be removed from
kernel memory later.

The patch 15/15 is one example to apply the firmware cache mechanism on
ath9k-htc driver.

Even there are some corener cases[3] which can't be solved by the
cache approach, but as discussed in[4], the problem can be easily
fixed by a simple patch written by Linus.

This patch set is against 3.6.0-rc1-next-20120803.

[1]. http://marc.info/?t=134278790800004&r=1&w=2
[2]. http://marc.info/?t=132528956000002&r=10&w=2
[3]. http://marc.info/?l=linux-usb&m=132554118928398&w=2
[4]. http://marc.info/?l=linux-kernel&m=134323730805443&w=2  

--
V1:
	-handle vmap failure case(1/15)
	-fix a memory leak of 'firmware_buf'(5/15)
	-fix oops during failure path of requesting firmware(6/15)
	-fix vmap more than one time(6/15)
	-introduce __fw_lookup_buf to avoid code duplication(7/15)
	-fix comment of request_firmware_nowait(9/15)
	-avoid releasing lock in devres_for_each_res(11/15)
	-use new devres iterator API to create fw cache entry(12/15)
	-rename some functions and data structures(12/15)
	-some code style fixes

	Thanks for Borislav's review!

--
 drivers/base/devres.c                    |   42 ++
 drivers/base/firmware_class.c            |  764 ++++++++++++++++++++++++++----
 drivers/net/wireless/ath/ath9k/hif_usb.c |   34 +-
 drivers/net/wireless/ath/ath9k/hif_usb.h |    4 +-
 include/linux/device.h                   |    4 +
 include/linux/firmware.h                 |   15 +
 6 files changed, 747 insertions(+), 116 deletions(-)


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/