1. 09 Dec, 2011 1 commit
    • Srivatsa S. Bhat's avatar
      PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled() · b298d289
      Srivatsa S. Bhat authored
      Commit a144c6a6 (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: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      b298d289
  2. 08 Dec, 2011 6 commits
  3. 06 Dec, 2011 8 commits
  4. 24 Nov, 2011 1 commit
  5. 23 Nov, 2011 20 commits
  6. 22 Nov, 2011 4 commits