linux-toradex.git/drivers/base, branch v2.6.32.60

PM / Sleep: Fix read_unlock_usermodehelper() call.

2012-03-04T17:49:23+00:00

[ Upstream commit e4c89a508f4385a0cd8681c2749a2cd2fa476e40 ]

Commit b298d289
 "PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"
added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called
without read_lock_usermodehelper() when kmalloc() failed.

Signed-off-by: Tetsuo Handa 
Acked-by: Srivatsa S. Bhat 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Greg Kroah-Hartman

PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()

2012-03-04T17:49:23+00:00

[ Upstream commit b298d289c79211508f11cb50749b0d1d54eb244a ]

Commit a144c6a (PM: Print a warning if firmware is requested when tasks
are frozen) introduced usermodehelper_is_disabled() to warn and exit
immediately if firmware is requested when usermodehelpers are disabled.

However, it is racy. Consider the following scenario, currently used in
drivers/base/firmware_class.c:

...
if (usermodehelper_is_disabled())
        goto out;

/* Do actual work */
...

out:
        return err;

Nothing prevents someone from disabling usermodehelpers just after the check
in the 'if' condition, which means that it is quite possible to try doing the
"actual work" with usermodehelpers disabled, leading to undesirable
consequences.

In particular, this race condition in _request_firmware() causes task freezing
failures whenever suspend/hibernation is in progress because, it wrongly waits
to get the firmware/microcode image from userspace when actually the
usermodehelpers are disabled or userspace has been frozen.
Some of the example scenarios that cause freezing failures due to this race
are those that depend on userspace via request_firmware(), such as x86
microcode module initialization and microcode image reload.

Previous discussions about this issue can be found at:
http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591

This patch adds proper synchronization to fix this issue.

It is to be noted that this patchset fixes the freezing failures but doesn't
remove the warnings. IOW, it does not attempt to add explicit synchronization
to x86 microcode driver to avoid requesting microcode image at inopportune
moments. Because, the warnings were introduced to highlight such cases, in the
first place. And we need not silence the warnings, since we take care of the
*real* problem (freezing failure) and hence, after that, the warnings are
pretty harmless anyway.

Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

firmware loader: allow builtin firmware load even if usermodehelper is disabled

2012-03-04T17:49:23+00:00

[ Upstream commit caca9510ff4e5d842c0589110243d60927836222 ]

In commit a144c6a6c924 ("PM: Print a warning if firmware is requested
when tasks are frozen") we not only printed a warning if somebody tried
to load the firmware when tasks are frozen - we also failed the load.

But that check was done before the check for built-in firmware, and then
when we disallowed usermode helpers during bootup (commit 288d5abec831:
"Boot up with usermodehelper disabled"), that actually means that
built-in modules can no longer load their firmware even if the firmware
is built in too.  Which used to work, and some people depended on it for
the R100 driver.

So move the test for usermodehelper_is_disabled() down, to after
checking the built-in firmware.

This should fix:

	https://bugzilla.kernel.org/show_bug.cgi?id=40952

Reported-by: James Cloos 
Bisected-by: Elimar Riesebieter 
Cc: Michel Dänzer 
Cc: Rafael Wysocki 
Cc: Valdis Kletnieks 
Signed-off-by: Linus Torvalds 
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Greg Kroah-Hartman

PM: Print a warning if firmware is requested when tasks are frozen

2012-03-04T17:49:23+00:00

[ Upstream commit a144c6a6c924aa1da04dd77fb84b89927354fdff ]

Some drivers erroneously use request_firmware() from their ->resume()
(or ->thaw(), or ->restore()) callbacks, which is not going to work
unless the firmware has been built in.  This causes system resume to
stall until the firmware-loading timeout expires, which makes users
think that the resume has failed and reboot their machines
unnecessarily.  For this reason, make _request_firmware() print a
warning and return immediately with error code if it has been called
when tasks are frozen and it's impossible to start any new usermode
helpers.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Valdis Kletnieks 
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Greg Kroah-Hartman

firmware: Fix an oops on reading fw_priv->fw in sysfs loading file

2012-01-12T19:40:00+00:00

commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.

This oops was reported recently:
firmware_loading_store+0xf9/0x17b
dev_attr_store+0x20/0x22
sysfs_write_file+0x101/0x134
vfs_write+0xac/0xf3
sys_write+0x4a/0x6e
system_call_fastpath+0x16/0x1b

The complete backtrace was unfortunately not captured, but details can be found
here:
https://bugzilla.redhat.com/show_bug.cgi?id=769920

The cause is fairly clear.

Its caused by the fact that firmware_loading_store has a case 0 in its
switch statement that reads and writes the fw_priv->fw poniter without the
protection of the fw_lock mutex.  since there is a window between the time that
_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
file is unregistered, its possible for a user space application to race in, and
write a zero to the loading file, causing a NULL dereference in
firmware_loading_store.  Fix it by extending the protection of the fw_lock mutex
to cover all of the firware_loading_store function.

Signed-off-by: Neil Horman 
Signed-off-by: Greg Kroah-Hartman

genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier

2011-11-26T17:10:36+00:00

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

v2: Fixed non-x86 build errors.

Signed-off-by: Ian Campbell 
Cc: Rafael J. Wysocki 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel 
Cc: Konrad Rzeszutek Wilk 
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Revert "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier"

2011-11-09T00:02:23+00:00

This reverts commit 0f12a6ad9fa3a03f2bcee36c9cb704821e244c40.

It causes too many build errors and needs to be done properly.

Reported-by: Jiri Slaby 
Reported-by: Christoph Biedl 
Cc: Ian Campbell 
Cc: Rafael J. Wysocki 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel 
Cc: Konrad Rzeszutek Wilk 
Cc: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier

2011-11-07T20:32:43+00:00

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

Signed-off-by: Ian Campbell 
Cc: Rafael J. Wysocki 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel 
Cc: Konrad Rzeszutek Wilk 
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

firmware_class: fix memory leak - free allocated pages

2010-08-02T17:21:25+00:00

commit dd336c554d8926c3348a2d5f2a5ef5597f6d1a06 upstream.

fix memory leak introduced by the patch 6e03a201bbe:
firmware: speed up request_firmware()

1. vfree won't release pages there were allocated explicitly and mapped
using vmap. The memory has to be vunmap-ed and the pages needs
to be freed explicitly

2. page array is moved into the 'struct
firmware' so that we can free it from release_firmware()
and not only in fw_dev_release()

The fix doesn't break the firmware load speed.

Cc: Johannes Berg 
Cc: Ming Lei 
Cc: Catalin Marinas 
Singed-off-by: Kay Sievers 
Signed-off-by: David Woodhouse 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman

drivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline

2010-07-05T18:10:40+00:00

commit cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 upstream.

Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads
to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even
possible to be displayed as offline.

Signed-off-by: Jan Beulich 
Cc: Andi Kleen 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman