From: Ingo Molnar <mingo@kernel.org>
To: Chen Yu <yu.c.chen@intel.com>
Cc: tglx@linutronix.de, mingo@redhat.com, rjw@rjwysocki.net,
pavel@ucw.cz, hpa@zytor.com, len.brown@intel.com,
yinghai@kernel.org, joeyli.kernel@gmail.com, rui.zhang@intel.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] PM / hibernate: Remove the restriction when checking memory size before/after hibernation
Date: Fri, 28 Aug 2015 07:37:52 +0200 [thread overview]
Message-ID: <20150828053751.GD26741@gmail.com> (raw)
In-Reply-To: <1392db911417124cd85cd8c169c5bc2de4ea5de1.1440640658.git.yu.c.chen@intel.com>
* Chen Yu <yu.c.chen@intel.com> wrote:
> Sometimes the resuming of hibernation might fail, because the
> system before/after hibernation have different number of page
> frames, and in current implementation, this situation will be
> regarded as invalud resuming process. However, consider the following
> scenario: The resuming system has a larger memory capacity than
> the one before hibernation, and the former memory region is a
> superset of the latter, it should be allowed to resume. For example,
> someone plugs more DRAMs before resuming from hibernation.
> Here's a case for this situation:
>
> e820 memory map before hibernation:
> BIOS-e820: [mem 0x0000000020200000-0x0000000077517fff] usable
> BIOS-e820: [mem 0x0000000077518000-0x0000000077567fff] reserved
>
> e820 memory map during resuming:
> BIOS-e820: [mem 0x0000000020200000-0x000000007753ffff] usable
> BIOS-e820: [mem 0x0000000077540000-0x0000000077567fff] reserved
>
> In current code, the resuming process will be terminated, because
> they have different memory size(usable region), but actually we should
> let it continue to resume because [0x0000000020200000-0x000000007753ffff]
> is a superset of [0x0000000020200000-0x0000000077517fff].
>
> This patch removes the constraint that number of page frames should
> be strictly the same before/after hibernation.
>
> Note: This patch can only work after:
> Commit ec93ef809f34 ("PM / hibernate: avoid unsafe pages in e820
> reserved regions") applied.
>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
> kernel/power/snapshot.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index c24d5a2..5b1a071 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -2072,8 +2072,12 @@ static int check_header(struct swsusp_info *info)
> char *reason;
>
> reason = check_image_kernel(info);
> - if (!reason && info->num_physpages != get_num_physpages())
> - reason = "memory size";
> + /*
> + * No need to check num_physpages with get_num_physpages
> + * as we did before(please refer to git log), because
> + * is_nosave_page will ensure that each page is safe
> + * to be restored.
> + */
> if (reason) {
> printk(KERN_ERR "PM: Image mismatch: %s\n", reason);
> return -EPERM;
No, this removes a useful sanity check that protects against data corruption.
If you want to relax it then you should add code that checks whether the
before/after memory image is truly a superset of each other, and warn and deny the
hibernation in any other case. (For example when RAM got removed or moved.)
Thanks,
Ingo
next prev parent reply other threads:[~2015-08-28 5:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 7:05 [PATCH 0/3] PM / hibernate: Fix hibernation panic caused by inconsistent e820 memory map Chen Yu
2015-08-27 7:05 ` [PATCH 1/3] x86: Kill E820_RESERVED_KERN Chen Yu
2015-08-27 7:06 ` [PATCH 2/3] PM / hibernate: avoid unsafe pages in e820 reserved regions Chen Yu
2015-08-27 7:06 ` [PATCH 3/3] PM / hibernate: Remove the restriction when checking memory size before/after hibernation Chen Yu
2015-08-28 5:37 ` Ingo Molnar [this message]
2015-09-01 9:54 ` Chen, Yu C
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=20150828053751.GD26741@gmail.com \
--to=mingo@kernel.org \
--cc=hpa@zytor.com \
--cc=joeyli.kernel@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
--cc=yinghai@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.