linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACVXFVM_WY4v69jdQiG13B94rEPP1EzHXpetZRrTJwhmgT=S2w@mail.gmail.com>
Date:	Fri, 10 Aug 2012 15:30:14 +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: Re: [RFC PATCH v1 00/15] firmware loader: introduce cache/uncache firmware

On Sat, Aug 4, 2012 at 12:01 PM, Ming Lei <ming.lei@...onical.com> wrote:
> 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!

Gentle ping on -V1, :-)

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/