[PATCH v2 0/8] firmware_class: Fix problems with usermodehelper test

From: Rafael J. Wysocki
Date: Wed Mar 28 2012 - 17:23:00 EST

Hi all,

On Monday, March 26, 2012, Rafael J. Wysocki wrote:
> The following series of patches fixes two problems with
> request_firmware() and request_firmware_nowait() resulting from commit
> a144c6a6c924aa1da04dd77fb84b89927354fdff
> PM: Print a warning if firmware is requested when tasks are frozen
> The first problem is that request_firmware_nowait() may fail if it happens
> to run in parallel with system suspend. It should't fail in such situations
> and that is addressed by the first three patches (that code has been discussed
> with Linus at al already).
> The second issue is that request_firmware() may be called in a thread which
> isn't related to system suspend and if suspend happens exactly at that time,
> request_firmware() will fail (and print a scary warning), although it shouldn't.
> This problem is addressed by the remaining three patches, which are new.

The following series is a respin of this one including fixes of minor bugs
found by the reviewers in the previous version and two additional patches
from Stephen cleaning up things a bit more.

Since patches [1-6/8] fix regressions, I'd like the series to go into v3.4
if that's not too late.

[1/8] - Rework the usermodehelper check in _request_firmware().
[2/8] - Split _request_firmware() into three functions.
[3/8] - If firmware is to be loaded asynchronously, wait for usermodehelper_disabled
to be unset instead of failing the operation.
[4/8] - Unify the hibernation/suspend code's usage of usermodehelper_disable().
[5/8] - Move usermodehelper_disable() into freeze_processes().
[6/8] - Make freezable threads calling request_firware() avoid the race with the
[7/8] - Split up fw_create_instance() to avoid casting out of const in it.
[8/8] - Use workqueues instead of kthreads in request_firmware_nowait().


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