1. 09 Dec, 2017 1 commit
  2. 22 Jul, 2017 2 commits
  3. 29 Jun, 2017 1 commit
  4. 02 Mar, 2017 1 commit
  5. 27 Feb, 2017 2 commits
  6. 07 Feb, 2017 1 commit
  7. 13 Sep, 2016 1 commit
  8. 12 Aug, 2016 1 commit
  9. 22 Jul, 2016 1 commit
    • Chen Yu's avatar
      PM / hibernate: Introduce test_resume mode for hibernation · fe12c00d
      Chen Yu authored
      test_resume mode is to verify if the snapshot data
      written to swap device can be successfully restored
      to memory. It is useful to ease the debugging process
      on hibernation, since this mode can not only bypass
      the BIOSes/bootloader, but also the system re-initialization.
      To avoid the risk to break the filesystm on persistent storage,
      this patch resumes the image with tasks frozen.
      For example:
      echo test_resume > /sys/power/disk
      echo disk > /sys/power/state
      [  187.306470] PM: Image saving progress:  70%
      [  187.395298] PM: Image saving progress:  80%
      [  187.476697] PM: Image saving progress:  90%
      [  187.554641] PM: Image saving done.
      [  187.558896] PM: Wrote 594600 kbytes in 0.90 seconds (660.66 MB/s)
      [  187.566000] PM: S|
      [  187.589742] PM: Basic memory bitmaps freed
      [  187.594694] PM: Checking hibernation image
      [  187.599865] PM: Image signature found, resuming
      [  187.605209] PM: Loading hibernation image.
      [  187.665753] PM: Basic memory bitmaps created
      [  187.691397] PM: Using 3 thread(s) for decompression.
      [  187.691397] PM: Loading and decompressing image data (148650 pages)...
      [  187.889719] PM: Image loading progress:   0%
      [  188.100452] PM: Image loading progress:  10%
      [  188.244781] PM: Image loading progress:  20%
      [  189.057305] PM: Image loading done.
      [  189.068793] PM: Image successfully loaded
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  10. 15 Jul, 2016 1 commit
    • Rafael J. Wysocki's avatar
      x86 / hibernate: Use hlt_play_dead() when resuming from hibernation · 406f992e
      Rafael J. Wysocki authored
      On Intel hardware, native_play_dead() uses mwait_play_dead() by
      default and only falls back to the other methods if that fails.
      That also happens during resume from hibernation, when the restore
      (boot) kernel runs disable_nonboot_cpus() to take all of the CPUs
      except for the boot one offline.
      However, that is problematic, because the address passed to
      __monitor() in mwait_play_dead() is likely to be written to in the
      last phase of hibernate image restoration and that causes the "dead"
      CPU to start executing instructions again.  Unfortunately, the page
      containing the address in that CPU's instruction pointer may not be
      valid any more at that point.
      First, that page may have been overwritten with image kernel memory
      contents already, so the instructions the CPU attempts to execute may
      simply be invalid.  Second, the page tables previously used by that
      CPU may have been overwritten by image kernel memory contents, so the
      address in its instruction pointer is impossible to resolve then.
      A report from Varun Koyyalagunta and investigation carried out by
      Chen Yu show that the latter sometimes happens in practice.
      To prevent it from happening, temporarily change the smp_ops.play_dead
      pointer during resume from hibernation so that it points to a special
      "play dead" routine which uses hlt_play_dead() and avoids the
      inadvertent "revivals" of "dead" CPUs this way.
      A slightly unpleasant consequence of this change is that if the
      system is hibernated with one or more CPUs offline, it will generally
      draw more power after resume than it did before hibernation, because
      the physical state entered by CPUs via hlt_play_dead() is higher-power
      than the mwait_play_dead() one in the majority of cases.  It is
      possible to work around this, but it is unclear how much of a problem
      that's going to be in practice, so the workaround will be implemented
      later if it turns out to be necessary.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=106371Reported-by: default avatarVarun Koyyalagunta <cpudebug@centtech.com>
      Original-by: default avatarChen Yu <yu.c.chen@intel.com>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
  11. 10 Jul, 2016 1 commit
    • Rafael J. Wysocki's avatar
      PM / hibernate: Image data protection during restoration · 4c0b6c10
      Rafael J. Wysocki authored
      Make it possible to protect all pages holding image data during
      hibernate image restoration by setting them read-only (so as to
      catch attempts to write to those pages after image data have been
      stored in them).
      This adds overhead to image restoration code (it may cause large
      page mappings to be split as a result of page flags changes) and
      the errors it protects against should never happen in theory, so
      the feature is only active after passing hibernate=protect_image
      to the command line of the restore kernel.
      Also it only is built if CONFIG_DEBUG_RODATA is set.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  12. 09 Jul, 2016 1 commit
  13. 27 Jun, 2016 1 commit
  14. 26 Jun, 2016 1 commit
    • Kees Cook's avatar
      x86/KASLR, x86/power: Remove x86 hibernation restrictions · 65fe935d
      Kees Cook authored
      With the following fix:
        70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code passes control to the image kernel")
      ... there is no longer a problem with hibernation resuming a
      KASLR-booted kernel image, so remove the restriction.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux PM list <linux-pm@vger.kernel.org>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160613221002.GA29719@www.outflux.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  15. 23 Mar, 2016 1 commit
    • Lukas Wunner's avatar
      PM / sleep: Clear pm_suspend_global_flags upon hibernate · 27614273
      Lukas Wunner authored
      When suspending to RAM, waking up and later suspending to disk,
      we gratuitously runtime resume devices after the thaw phase.
      This does not occur if we always suspend to RAM or always to disk.
      pm_complete_with_resume_check(), which gets called from
      pci_pm_complete() among others, schedules a runtime resume
      if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during
      a suspend-to-RAM cycle. It is cleared at the beginning of
      the suspend-to-RAM cycle but not afterwards and it is not
      cleared during a suspend-to-disk cycle at all. Fix it.
      Fixes: ef25ba04 (PM / sleep: Add flags to indicate platform firmware involvement)
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  16. 15 Mar, 2016 1 commit
    • Laura Abbott's avatar
      mm/page_poisoning.c: allow for zero poisoning · 1414c7f4
      Laura Abbott authored
      By default, page poisoning uses a poison value (0xaa) on free.  If this
      is changed to 0, the page is not only sanitized but zeroing on alloc
      with __GFP_ZERO can be skipped as well.  The tradeoff is that detecting
      corruption from the poisoning is harder to detect.  This feature also
      cannot be used with hibernation since pages are not guaranteed to be
      zeroed after hibernation.
      Credit to Grsecurity/PaX team for inspiring this work
      Signed-off-by: default avatarLaura Abbott <labbott@fedoraproject.org>
      Acked-by: default avatarRafael J. Wysocki <rjw@rjwysocki.net>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Jianyu Zhan <nasa4836@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 14 Oct, 2015 1 commit
  18. 24 Jun, 2015 1 commit
  19. 03 Nov, 2014 1 commit
  20. 27 Oct, 2014 1 commit
  21. 17 Jul, 2014 1 commit
  22. 16 Jun, 2014 2 commits
  23. 06 Jun, 2014 1 commit
    • Todd E Brandt's avatar
      PM / sleep: trace events for suspend/resume · bb3632c6
      Todd E Brandt authored
      Adds trace events that give finer resolution into suspend/resume. These
      events are graphed in the timelines generated by the analyze_suspend.py
      script. They represent large areas of time consumed that are typical to
      suspend and resume.
      The event is triggered by calling the function "trace_suspend_resume"
      with three arguments: a string (the name of the event to be displayed
      in the timeline), an integer (case specific number, such as the power
      state or cpu number), and a boolean (where true is used to denote the start
      of the timeline event, and false to denote the end).
      The suspend_resume trace event reproduces the data that the machine_suspend
      trace event did, so the latter has been removed.
      Signed-off-by: default avatarTodd Brandt <todd.e.brandt@intel.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  24. 16 May, 2014 1 commit
  25. 09 May, 2014 1 commit
  26. 30 Apr, 2014 1 commit
  27. 28 Apr, 2014 1 commit
  28. 01 Mar, 2014 1 commit
  29. 06 Jan, 2014 1 commit
    • Bjørn Mork's avatar
      PM / hibernate: Call platform_leave() in suspend path too · 362e77d1
      Bjørn Mork authored
      Since create_image() only executes platform_leave() if in_suspend is
      not set, enable_nonboot_cpus() is run by it with EC transactions
      blocked (on ACPI systems) in the image creation code path (that is,
      for in_suspend set), which may cause CPU online to fail for the CPUs
      in question.  In particular, this causes the acpi_cpufreq driver's
      initialization to fail for those CPUs on some systems with the
      following dmesg:
       cpufreq: adding CPU 1
       cpufreq: FREQ: 1401000 - CPU: 0
       ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20130725/evregion-287)
       ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.LPMD] (Node ffff88023249ab28), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Error: Method parse/execution failed [\_PR_.CPU0._PPC] (Node ffff88023270e3f8), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Error: Method parse/execution failed [\_PR_.CPU1._PPC] (Node ffff88023270e290), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Exception: AE_BAD_PARAMETER, Evaluating _PPC (20130725/processor_perflib-140)
       cpufreq: initialization failed
       CPU1 is up
      To fix this problem, modify create_image() to execute platform_leave()
      unconditionally.  [rjw: This shouldn't lead to any significant side
      effects on ACPI systems.]
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      [rjw: Changelog]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  30. 30 Nov, 2013 1 commit
  31. 24 Oct, 2013 1 commit
  32. 31 Aug, 2013 2 commits
    • Rafael J. Wysocki's avatar
      PM / hibernate / memory hotplug: Rework mutual exclusion · 942f4015
      Rafael J. Wysocki authored
      Since all of the memory hotplug operations have to be carried out
      under device_hotplug_lock, they won't need to acquire pm_mutex if
      device_hotplug_lock is held around hibernation.
      For this reason, make the hibernation code acquire
      device_hotplug_lock after freezing user space processes and
      release it before thawing them.  At the same tim drop the
      lock_system_sleep() and unlock_system_sleep() calls from
      lock_memory_hotplug() and unlock_memory_hotplug(), respectively.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
    • Rafael J. Wysocki's avatar
      PM / hibernate: Create memory bitmaps after freezing user space · 8fd37a4c
      Rafael J. Wysocki authored
      The hibernation core uses special memory bitmaps during image
      creation and restoration and traditionally those bitmaps are
      allocated before freezing tasks, because in the past GFP_KERNEL
      allocations might not work after all tasks had been frozen.
      However, this is an anachronism, because hibernation_snapshot()
      now calls hibernate_preallocate_memory() which allocates memory
      for the image upfront anyway, so the memory bitmaps may be
      allocated after freezing user space safely.
      For this reason, move all of the create_basic_memory_bitmaps()
      calls after freeze_processes() and all of the corresponding
      free_basic_memory_bitmaps() calls before thaw_processes().
      This will allow us to hold device_hotplug_lock around hibernation
      without the need to worry about freezing issues with user space
      processes attempting to acquire it via sysfs attributes after the
      creation of memory bitmaps and before the freezing of tasks.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
  33. 06 Aug, 2013 1 commit
  34. 19 Jul, 2012 1 commit
    • Linus Torvalds's avatar
      Make wait_for_device_probe() also do scsi_complete_async_scans() · eea03c20
      Linus Torvalds authored
      Commit a7a20d10 ("sd: limit the scope of the async probe domain")
      make the SCSI device probing run device discovery in it's own async
      However, as a result, the partition detection was no longer synchronized
      by async_synchronize_full() (which, despite the name, only synchronizes
      the global async space, not all of them).  Which in turn meant that
      "wait_for_device_probe()" would not wait for the SCSI partitions to be
      And "wait_for_device_probe()" was what the boot time init code relied on
      for mounting the root filesystem.
      Now, most people never noticed this, because not only is it
      timing-dependent, but modern distributions all use initrd.  So the root
      filesystem isn't actually on a disk at all.  And then before they
      actually mount the final disk filesystem, they will have loaded the
      scsi-wait-scan module, which not only does the expected
      wait_for_device_probe(), but also does scsi_complete_async_scans().
      [ Side note: scsi_complete_async_scans() had also been partially broken,
        but that was fixed in commit 43a8d39d ("fix async probe
        regression"), so that same commit a7a20d10 had actually broken
        setups even if you used scsi-wait-scan explicitly ]
      Solve this problem by just moving the scsi_complete_async_scans() call
      into wait_for_device_probe().  Everybody who wants to wait for device
      probing to finish really wants the SCSI probing to complete, so there's
      no reason not to do this.
      So now "wait_for_device_probe()" really does what the name implies, and
      properly waits for device probing to finish.  This also removes the now
      unnecessary extra calls to scsi_complete_async_scans().
      Reported-and-tested-by: default avatarArtem S. Tashkinov <t.artem@mailcity.com>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <jbottomley@parallels.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: linux-scsi <linux-scsi@vger.kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  35. 01 Jul, 2012 2 commits