On Thu 2014-08-07 18:17:34, joeyli wrote:
> On Thu, Aug 07, 2014 at 11:39:57AM +0200, Pavel Machek wrote:
> > > > Actually, if you are doing such a check... it makes sense to check for
> > > > _all_ the regions, nosave or not. If e820 map changed at all, it is
> > > > not safe to resume.
> > > >
> > > > Pavel
> > >
> > > Currently nosave region only called register by e820 code, so hibernate's
> > > nosave region included e820
> > > reserved, ACPI data and ACPI NVS region.
> > >
> > > I thought hashing the start/end pfn of above regions is enough.
> >
> > If ammount of memory changed, for example, it is unsafe to
> > resume. So if you are doing the check, anyway, please hash
> > whole e820 table.
>
> There already have num_physpages in header for check the total physical page
> number.
Good, but if ammount of memory stayed the same, but offsets
changed (for example), resume is unsafe, too.
When I wrote that num_physpages check, I should have checked
whole e820 table, instead. (If anything at all changed there,
"new" kernel is running with wrong e820 info).
You seem to be in great position to fix that mistake now...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
