All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Chen Yu <yu.c.chen@intel.com>
Cc: linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Lee@amd.karlin.mff.cuni.cz, Chun-Yi <jlee@suse.com>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH][v8] PM / hibernate: Verify the consistent of e820 memory map by md5 value
Date: Sun, 28 Aug 2016 18:36:59 +0200	[thread overview]
Message-ID: <20160828163659.GA19306@amd> (raw)
In-Reply-To: <1472402140-959-1-git-send-email-yu.c.chen@intel.com>

On Mon 2016-08-29 00:35:40, Chen Yu wrote:
> On some platforms, there is occasional panic triggered when trying to
> resume from hibernation, a typical panic looks like:
> 
> "BUG: unable to handle kernel paging request at ffff880085894000
> IP: [<ffffffff810c5dc2>] load_image_lzo+0x8c2/0xe70"
> 
> This is because e820 map has been changed by BIOS across
> hibernation, and one of the page frames from first kernel
> is right located in second kernel's unmapped region, so panic
> comes out when accessing unmapped kernel address.
> 
> In order to expose this issue earlier, the md5 hash of e820 map
> is passed from suspend kernel to resume kernel, and the system will
> trigger panic once it finds the md5 value of previous kernel is not
> the same as current resume kernel.
> 
> Note:
> 1. Without this patch applied, it is possible that BIOS has
>    provided an inconsistent memory map, but the resume kernel is still
>    able to restore the image anyway(e.g.,  E820_RAM region is the subset
>    of the previous one), although the system might be unstable. So this
>    patch tries to treat any inconsistent e820 as illegal.
> 
> 2. Another case is, this patch replies on comparing the e820_saved, but
>    currently the e820_save might not be strictly the same across
>    hibernation, even if BIOS has provided consistent e820 map - In
>    theory mptable might modify the BIOS-provided e820_saved dynamically
>    in early_reserve_e820_mpc_new, which would allocate a buffer from
>    E820_RAM, and marks it from E820_RAM to E820_RESERVED). 
>    This is a potential and rare case we need to deal with in OS in
>    the future.
> 
> Suggested-by: Pavel Machek <pavel@ucw.cz>
> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Lee, Chun-Yi <jlee@suse.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>

Acked-by: Pavel Machek <pavel@ucw.cz>

You might want to verify that panic is actually visible on affected
platform. Thanks for your patience ;-).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2016-08-28 16:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-28 16:35 [PATCH][v8] PM / hibernate: Verify the consistent of e820 memory map by md5 value Chen Yu
2016-08-28 16:36 ` Pavel Machek [this message]
2016-08-29  4:59 ` Borislav Petkov
2016-08-29  7:15   ` Pavel Machek
2016-08-29 13:41     ` Borislav Petkov
2016-08-30  8:35       ` joeyli
2016-08-30 11:54         ` Rafael J. Wysocki
2016-09-08 21:15           ` Pavel Machek
2016-09-09  7:36             ` Chen Yu
2016-09-09  7:33               ` Pavel Machek
2016-08-30 11:51       ` Rafael J. Wysocki
2016-08-29 13:41   ` Rafael J. Wysocki
2016-08-29 15:13     ` Pavel Machek
2016-08-30 12:04       ` Rafael J. Wysocki
2016-08-30 19:53         ` Pavel Machek
2016-08-30 21:50           ` Rafael J. Wysocki
2016-08-31 11:03             ` Pavel Machek
2016-08-31  0:27 ` Rafael J. Wysocki
2016-08-31 11:07   ` Pavel Machek
2016-08-31 11:43     ` Pavel Machek
2016-08-31 11:54       ` Rafael J. Wysocki
  -- strict thread matches above, loose matches on Subject: below --
2016-08-29 21:08 Prarit Bhargava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160828163659.GA19306@amd \
    --to=pavel@ucw.cz \
    --cc=Lee@amd.karlin.mff.cuni.cz \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jlee@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.