| Message ID | 1435679668-13806-1-git-send-email-yu.c.chen@intel.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Rafael Wysocki |
| Headers | show |
Hi Chen Yu, On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: > Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved > regions") was reverted, because this patch makes resume from hibernation > on Lenovo x230 unreliable. But reverting may bring back the kernel > exception firstly reported in former patch. In general, there are three > problems in current code when resuming from hibernation: > > 1.Resuming page may also be in second kernel's e820 reserved region. > BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved > this causes kernel exception described in Commit 84c91b7ae07c > ("PM / hibernate: avoid unsafe pages in e820 reserved regions") > > 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 > reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN > regions causes some regions at e820 table not page aligned, > e820_mark_nosave_regions will misjudgment the non-page aligned space to > be "hole" space and add to nosave regions, this causes resuming failed. > Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. > Sorry for I am not fully understand why checking pfn_valid could avoid the above 2. issue? Per my understood should waiting Yinghai Lu's patches for killing E820_RESERVED_KERN to avoid the aligned problem. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Joey thanks for your reply, On 2015?07?02? 14:19, joeyli wrote: > Hi Chen Yu, > > On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: >> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved >> regions") was reverted, because this patch makes resume from hibernation >> on Lenovo x230 unreliable. But reverting may bring back the kernel >> exception firstly reported in former patch. In general, there are three >> problems in current code when resuming from hibernation: >> >> 1.Resuming page may also be in second kernel's e820 reserved region. >> BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved >> this causes kernel exception described in Commit 84c91b7ae07c >> ("PM / hibernate: avoid unsafe pages in e820 reserved regions") >> >> 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 >> reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN >> regions causes some regions at e820 table not page aligned, >> e820_mark_nosave_regions will misjudgment the non-page aligned space to >> be "hole" space and add to nosave regions, this causes resuming failed. >> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. >> > > Sorry for I am not fully understand why checking pfn_valid could avoid > the above 2. issue? > [Yu] According to e820_mark_nosave_regions, two kinds of e820 regions will be regarded as nosave: a.e820.map holes between each e820entry b.e820entry with (!E820_RAM && !E820_RESERVED_KERN) dmesg in https://bugzilla.kernel.org/show_bug.cgi?id=96111 shows that: BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] usable PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] e820 map was changed by situation a, but it should not be added to nosave list, right? and according to saveable_page, only pages in the zone will be saved: if (page_zone(page_ != zone) return NULL; The function of is_valid_orig_page in this patch treats setup_data as valid page, so I think this workaround issue 2. > Per my understood should waiting Yinghai Lu's patches for killing > E820_RESERVED_KERN to avoid the aligned problem. [Yu] yes, it is a graceful solution, but I don't see that in 4.1? And we encountered problem 3 in our testing enviroment, so I wrote a patch to deal with it first. > > > Thanks a lot! > Joey Lee > Best Regards, Yu -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Chen Yu, On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: > Hi, Joey > thanks for your reply, > > On 2015?07?02? 14:19, joeyli wrote: > >Hi Chen Yu, > > > >On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: > >>Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved > >>regions") was reverted, because this patch makes resume from hibernation > >>on Lenovo x230 unreliable. But reverting may bring back the kernel > >>exception firstly reported in former patch. In general, there are three > >>problems in current code when resuming from hibernation: > >> > >>1.Resuming page may also be in second kernel's e820 reserved region. > >>BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved > >>this causes kernel exception described in Commit 84c91b7ae07c > >>("PM / hibernate: avoid unsafe pages in e820 reserved regions") > >> > >>2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 > >>reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN > >>regions causes some regions at e820 table not page aligned, > >>e820_mark_nosave_regions will misjudgment the non-page aligned space to > >>be "hole" space and add to nosave regions, this causes resuming failed. > >>Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. > >> > > > >Sorry for I am not fully understand why checking pfn_valid could avoid > >the above 2. issue? > > > [Yu] According to e820_mark_nosave_regions, two kinds of e820 > regions will be regarded as nosave: > a.e820.map holes between each e820entry > b.e820entry with (!E820_RAM && !E820_RESERVED_KERN) > dmesg in > https://bugzilla.kernel.org/show_bug.cgi?id=96111 > shows that: > > BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable > reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] usable > PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] > > e820 map was changed by situation a, but it should not be added to > nosave list, right? > > and according to saveable_page, only pages in the zone will be saved: > if (page_zone(page_ != zone) > return NULL; > > The function of is_valid_orig_page in this patch treats setup_data as > valid page, so I think this workaround issue 2. > > > >Per my understood should waiting Yinghai Lu's patches for killing > >E820_RESERVED_KERN to avoid the aligned problem. > [Yu] yes, it is a graceful solution, but I don't see that in 4.1? And > we encountered problem 3 in our testing enviroment, so I wrote a patch > to deal with it first. > > > > > >Thanks a lot! > >Joey Lee > > Thanks for your explanation, then your patch makes sense to me. Please feel free to add tag: Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, July 06, 2015 04:37:39 PM joeyli wrote: > Hi Chen Yu, > > On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: > > Hi, Joey > > thanks for your reply, > > > > On 2015?07?02? 14:19, joeyli wrote: > > >Hi Chen Yu, > > > > > >On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: > > >>Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved > > >>regions") was reverted, because this patch makes resume from hibernation > > >>on Lenovo x230 unreliable. But reverting may bring back the kernel > > >>exception firstly reported in former patch. In general, there are three > > >>problems in current code when resuming from hibernation: > > >> > > >>1.Resuming page may also be in second kernel's e820 reserved region. > > >>BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved > > >>this causes kernel exception described in Commit 84c91b7ae07c > > >>("PM / hibernate: avoid unsafe pages in e820 reserved regions") > > >> > > >>2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 > > >>reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN > > >>regions causes some regions at e820 table not page aligned, > > >>e820_mark_nosave_regions will misjudgment the non-page aligned space to > > >>be "hole" space and add to nosave regions, this causes resuming failed. > > >>Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. > > >> > > > > > >Sorry for I am not fully understand why checking pfn_valid could avoid > > >the above 2. issue? > > > > > [Yu] According to e820_mark_nosave_regions, two kinds of e820 > > regions will be regarded as nosave: > > a.e820.map holes between each e820entry > > b.e820entry with (!E820_RAM && !E820_RESERVED_KERN) > > dmesg in > > https://bugzilla.kernel.org/show_bug.cgi?id=96111 > > shows that: > > > > BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable > > reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] usable > > PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] > > > > e820 map was changed by situation a, but it should not be added to > > nosave list, right? > > > > and according to saveable_page, only pages in the zone will be saved: > > if (page_zone(page_ != zone) > > return NULL; > > > > The function of is_valid_orig_page in this patch treats setup_data as > > valid page, so I think this workaround issue 2. > > > > > > >Per my understood should waiting Yinghai Lu's patches for killing > > >E820_RESERVED_KERN to avoid the aligned problem. > > [Yu] yes, it is a graceful solution, but I don't see that in 4.1? And > > we encountered problem 3 in our testing enviroment, so I wrote a patch > > to deal with it first. > > > > > > > > >Thanks a lot! > > >Joey Lee > > > > > Thanks for your explanation, then your patch makes sense to me. > > Please feel free to add tag: > > Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> Patch queued up for 4.3, thanks!
On 2015?07?16? 08:30, Rafael J. Wysocki wrote: > On Monday, July 06, 2015 04:37:39 PM joeyli wrote: >> Hi Chen Yu, >> >> On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: >>> Hi, Joey >>> thanks for your reply, >>> >>> On 2015?07?02? 14:19, joeyli wrote: >>>> Hi Chen Yu, >>>> >>>> On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: >>>>> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved >>>>> regions") was reverted, because this patch makes resume from hibernation >>>>> on Lenovo x230 unreliable. But reverting may bring back the kernel >>>>> exception firstly reported in former patch. In general, there are three >>>>> problems in current code when resuming from hibernation: >>>>> >>>>> 1.Resuming page may also be in second kernel's e820 reserved region. >>>>> BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved >>>>> this causes kernel exception described in Commit 84c91b7ae07c >>>>> ("PM / hibernate: avoid unsafe pages in e820 reserved regions") >>>>> >>>>> 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 >>>>> reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN >>>>> regions causes some regions at e820 table not page aligned, >>>>> e820_mark_nosave_regions will misjudgment the non-page aligned space to >>>>> be "hole" space and add to nosave regions, this causes resuming failed. >>>>> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. >>>>> >>>> >>>> Sorry for I am not fully understand why checking pfn_valid could avoid >>>> the above 2. issue? >>>> >>> [Yu] According to e820_mark_nosave_regions, two kinds of e820 >>> regions will be regarded as nosave: >>> a.e820.map holes between each e820entry >>> b.e820entry with (!E820_RAM && !E820_RESERVED_KERN) >>> dmesg in >>> https://bugzilla.kernel.org/show_bug.cgi?id=96111 >>> shows that: >>> >>> BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable >>> reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] usable >>> PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] >>> >>> e820 map was changed by situation a, but it should not be added to >>> nosave list, right? >>> >>> and according to saveable_page, only pages in the zone will be saved: >>> if (page_zone(page_ != zone) >>> return NULL; >>> >>> The function of is_valid_orig_page in this patch treats setup_data as >>> valid page, so I think this workaround issue 2. >>> >>> >>>> Per my understood should waiting Yinghai Lu's patches for killing >>>> E820_RESERVED_KERN to avoid the aligned problem. >>> [Yu] yes, it is a graceful solution, but I don't see that in 4.1? And >>> we encountered problem 3 in our testing enviroment, so I wrote a patch >>> to deal with it first. >>>> >>>> >>>> Thanks a lot! >>>> Joey Lee >>>> >> >> Thanks for your explanation, then your patch makes sense to me. >> >> Please feel free to add tag: >> >> Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> > > Patch queued up for 4.3, thanks! > Hi Rafeal, Please help drop this patch for now, QA has found some problems with this patch applied, we're working on it now. Sorry for inconvenience. Regards, Yu -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, July 21, 2015 09:28:32 AM chenyu5 wrote: > On 2015?07?16? 08:30, Rafael J. Wysocki wrote: > > On Monday, July 06, 2015 04:37:39 PM joeyli wrote: > >> Hi Chen Yu, > >> > >> On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: > >>> Hi, Joey > >>> thanks for your reply, > >>> > >>> On 2015?07?02? 14:19, joeyli wrote: > >>>> Hi Chen Yu, > >>>> > >>>> On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: > >>>>> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved > >>>>> regions") was reverted, because this patch makes resume from hibernation > >>>>> on Lenovo x230 unreliable. But reverting may bring back the kernel > >>>>> exception firstly reported in former patch. In general, there are three > >>>>> problems in current code when resuming from hibernation: > >>>>> > >>>>> 1.Resuming page may also be in second kernel's e820 reserved region. > >>>>> BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved > >>>>> this causes kernel exception described in Commit 84c91b7ae07c > >>>>> ("PM / hibernate: avoid unsafe pages in e820 reserved regions") > >>>>> > >>>>> 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 > >>>>> reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN > >>>>> regions causes some regions at e820 table not page aligned, > >>>>> e820_mark_nosave_regions will misjudgment the non-page aligned space to > >>>>> be "hole" space and add to nosave regions, this causes resuming failed. > >>>>> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. > >>>>> > >>>> > >>>> Sorry for I am not fully understand why checking pfn_valid could avoid > >>>> the above 2. issue? > >>>> > >>> [Yu] According to e820_mark_nosave_regions, two kinds of e820 > >>> regions will be regarded as nosave: > >>> a.e820.map holes between each e820entry > >>> b.e820entry with (!E820_RAM && !E820_RESERVED_KERN) > >>> dmesg in > >>> https://bugzilla.kernel.org/show_bug.cgi?id=96111 > >>> shows that: > >>> > >>> BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable > >>> reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] usable > >>> PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] > >>> > >>> e820 map was changed by situation a, but it should not be added to > >>> nosave list, right? > >>> > >>> and according to saveable_page, only pages in the zone will be saved: > >>> if (page_zone(page_ != zone) > >>> return NULL; > >>> > >>> The function of is_valid_orig_page in this patch treats setup_data as > >>> valid page, so I think this workaround issue 2. > >>> > >>> > >>>> Per my understood should waiting Yinghai Lu's patches for killing > >>>> E820_RESERVED_KERN to avoid the aligned problem. > >>> [Yu] yes, it is a graceful solution, but I don't see that in 4.1? And > >>> we encountered problem 3 in our testing enviroment, so I wrote a patch > >>> to deal with it first. > >>>> > >>>> > >>>> Thanks a lot! > >>>> Joey Lee > >>>> > >> > >> Thanks for your explanation, then your patch makes sense to me. > >> > >> Please feel free to add tag: > >> > >> Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> > > > > Patch queued up for 4.3, thanks! > > > Hi Rafeal, > Please help drop this patch for now, QA has > found some problems with this patch applied, > we're working on it now. Sorry for inconvenience. Dropping, thanks for the heads up!
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFmYWVsIEouIFd5c29j a2kgW21haWx0bzpyandAcmp3eXNvY2tpLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIy LCAyMDE1IDk6MDQgQU0NCj4gVG86IENoZW4sIFl1IEMNCj4gQ2M6IGxpbnV4LXBtQHZnZXIua2Vy bmVsLm9yZzsgV3lzb2NraSwgUmFmYWVsIEo7IGpvZXlsaTsgVGlhbiwgWWVYDQo+IFN1YmplY3Q6 IFJlOiBbUkZDIFBBVENIXSBQTSAvIGhpYmVybmF0ZTogbWFrZSBzdXJlIGVhY2ggcmVzdW1pbmcg cGFnZSBpcw0KPiBpbiBjdXJyZW50IG1lbW9yeSB6b25lcw0KPiANCj4gT24gVHVlc2RheSwgSnVs eSAyMSwgMjAxNSAwOToyODozMiBBTSBjaGVueXU1IHdyb3RlOg0KPiA+IE9uIDIwMTXlubQwN+ac iDE25pelIDA4OjMwLCBSYWZhZWwgSi4gV3lzb2NraSB3cm90ZToNCj4gPiA+IE9uIE1vbmRheSwg SnVseSAwNiwgMjAxNSAwNDozNzozOSBQTSBqb2V5bGkgd3JvdGU6DQo+ID4gPj4gSGkgQ2hlbiBZ dSwNCj4gPiA+Pg0KPiA+ID4+IE9uIFRodSwgSnVsIDAyLCAyMDE1IGF0IDA0OjAwOjQyUE0gKzA4 MDAsIGNoZW55dTUgd3JvdGU6DQo+ID4gPj4+IEhpLCBKb2V5DQo+ID4gPj4+IHRoYW5rcyBmb3Ig eW91ciByZXBseSwNCj4gPiA+Pj4NCj4gPiA+Pj4gT24gMjAxNeW5tDA35pyIMDLml6UgMTQ6MTks IGpvZXlsaSB3cm90ZToNCj4gPiA+Pj4+IEhpIENoZW4gWXUsDQo+ID4gPj4+Pg0KPiA+ID4+Pj4g T24gVHVlLCBKdW4gMzAsIDIwMTUgYXQgMTE6NTQ6MjhQTSArMDgwMCwgQ2hlbiBZdSB3cm90ZToN Cj4gPiA+Pj4+PiBDb21taXQgODRjOTFiN2FlMDdjICgiUE0gLyBoaWJlcm5hdGU6IGF2b2lkIHVu c2FmZSBwYWdlcyBpbiBlODIwDQo+ID4gPj4+Pj4gcmVzZXJ2ZWQNCj4gPiA+Pj4+PiByZWdpb25z Iikgd2FzIHJldmVydGVkLCBiZWNhdXNlIHRoaXMgcGF0Y2ggbWFrZXMgcmVzdW1lIGZyb20NCj4g PiA+Pj4+PiBoaWJlcm5hdGlvbiBvbiBMZW5vdm8geDIzMCB1bnJlbGlhYmxlLiBCdXQgcmV2ZXJ0 aW5nIG1heSBicmluZw0KPiA+ID4+Pj4+IGJhY2sgdGhlIGtlcm5lbCBleGNlcHRpb24gZmlyc3Rs eSByZXBvcnRlZCBpbiBmb3JtZXIgcGF0Y2guIEluDQo+ID4gPj4+Pj4gZ2VuZXJhbCwgdGhlcmUg YXJlIHRocmVlIHByb2JsZW1zIGluIGN1cnJlbnQgY29kZSB3aGVuIHJlc3VtaW5nDQo+IGZyb20g aGliZXJuYXRpb246DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiAxLlJlc3VtaW5nIHBhZ2UgbWF5IGFs c28gYmUgaW4gc2Vjb25kIGtlcm5lbCdzIGU4MjAgcmVzZXJ2ZWQNCj4gcmVnaW9uLg0KPiA+ID4+ Pj4+IEJJT1MtZTgyMDogW21lbSAweDAwMDAwMDAwNjlkNGYwMDAtMHgwMDAwMDAwMDY5ZTEyZmZm XQ0KPiByZXNlcnZlZA0KPiA+ID4+Pj4+IHRoaXMgY2F1c2VzIGtlcm5lbCBleGNlcHRpb24gZGVz Y3JpYmVkIGluIENvbW1pdCA4NGM5MWI3YWUwN2MNCj4gPiA+Pj4+PiAoIlBNIC8gaGliZXJuYXRl OiBhdm9pZCB1bnNhZmUgcGFnZXMgaW4gZTgyMCByZXNlcnZlZCByZWdpb25zIikNCj4gPiA+Pj4+ Pg0KPiA+ID4+Pj4+IDIuSWYgQ29tbWl0IDg0YzkxYjdhZTA3YyAoIlBNIC8gaGliZXJuYXRlOiBh dm9pZCB1bnNhZmUgcGFnZXMgaW4NCj4gPiA+Pj4+PiBlODIwIHJlc2VydmVkIHJlZ2lvbnMiKSBp cyBhcHBsaWVkIHRvIGZpeCBwcm9ibGVtIDEsIGFuZCBpZg0KPiA+ID4+Pj4+IEU4MjBfUkVTRVJW RURfS0VSTiByZWdpb25zIGNhdXNlcyBzb21lIHJlZ2lvbnMgYXQgZTgyMCB0YWJsZQ0KPiBub3QN Cj4gPiA+Pj4+PiBwYWdlIGFsaWduZWQsIGU4MjBfbWFya19ub3NhdmVfcmVnaW9ucyB3aWxsIG1p c2p1ZGdtZW50IHRoZQ0KPiA+ID4+Pj4+IG5vbi1wYWdlIGFsaWduZWQgc3BhY2UgdG8gYmUgImhv bGUiIHNwYWNlIGFuZCBhZGQgdG8gbm9zYXZlDQo+IHJlZ2lvbnMsIHRoaXMgY2F1c2VzIHJlc3Vt aW5nIGZhaWxlZC4NCj4gPiA+Pj4+PiBSZWZlciB0byBodHRwczovL2J1Z3ppbGxhLmtlcm5lbC5v cmcvc2hvd19idWcuY2dpP2lkPTk2MTExIGZvcg0KPiBkZXRhaWwuDQo+ID4gPj4+Pj4NCj4gPiA+ Pj4+DQo+ID4gPj4+PiBTb3JyeSBmb3IgSSBhbSBub3QgZnVsbHkgdW5kZXJzdGFuZCB3aHkgY2hl Y2tpbmcgcGZuX3ZhbGlkIGNvdWxkDQo+ID4gPj4+PiBhdm9pZCB0aGUgYWJvdmUgMi4gaXNzdWU/ DQo+ID4gPj4+Pg0KPiA+ID4+PiBbWXVdIEFjY29yZGluZyB0byBlODIwX21hcmtfbm9zYXZlX3Jl Z2lvbnMsIHR3byBraW5kcyBvZiBlODIwDQo+ID4gPj4+IHJlZ2lvbnMgd2lsbCBiZSByZWdhcmRl ZCBhcyBub3NhdmU6DQo+ID4gPj4+IGEuZTgyMC5tYXAgaG9sZXMgYmV0d2VlbiBlYWNoIGU4MjBl bnRyeSBiLmU4MjBlbnRyeSB3aXRoDQo+ID4gPj4+ICghRTgyMF9SQU0gJiYgIUU4MjBfUkVTRVJW RURfS0VSTikgZG1lc2cgaW4NCj4gPiA+Pj4gaHR0cHM6Ly9idWd6aWxsYS5rZXJuZWwub3JnL3No b3dfYnVnLmNnaT9pZD05NjExMQ0KPiA+ID4+PiBzaG93cyB0aGF0Og0KPiA+ID4+Pg0KPiA+ID4+ PiBCSU9TLWU4MjA6IFttZW0gMHgwMDAwMDAwMDViYWZmMDAwLTB4MDAwMDAwMDBkNjg0ZmZmZl0g dXNhYmxlDQo+ID4gPj4+IHJlc2VydmUgc2V0dXBfZGF0YTogW21lbSAweDAwMDAwMDAwOWQzZTAw MTgtMHgwMDAwMDAwMDlkM2YwMDU3XQ0KPiA+ID4+PiB1c2FibGUNCj4gPiA+Pj4gUE06IFJlZ2lz dGVyZWQgbm9zYXZlIG1lbW9yeTogW21lbSAweDlkM2UwMDAwLTB4OWQzZTBmZmZdDQo+ID4gPj4+ DQo+ID4gPj4+IGU4MjAgbWFwIHdhcyBjaGFuZ2VkIGJ5IHNpdHVhdGlvbiBhLCBidXQgaXQgc2hv dWxkIG5vdCBiZSBhZGRlZCB0bw0KPiA+ID4+PiBub3NhdmUgbGlzdCwgcmlnaHQ/DQo+ID4gPj4+ DQo+ID4gPj4+IGFuZCBhY2NvcmRpbmcgdG8gc2F2ZWFibGVfcGFnZSwgb25seSBwYWdlcyBpbiB0 aGUgem9uZSB3aWxsIGJlIHNhdmVkOg0KPiA+ID4+PiBpZiAocGFnZV96b25lKHBhZ2VfICE9IHpv bmUpDQo+ID4gPj4+IAlyZXR1cm4gTlVMTDsNCj4gPiA+Pj4NCj4gPiA+Pj4gVGhlIGZ1bmN0aW9u IG9mIGlzX3ZhbGlkX29yaWdfcGFnZSBpbiB0aGlzIHBhdGNoIHRyZWF0cyBzZXR1cF9kYXRhDQo+ ID4gPj4+IGFzIHZhbGlkIHBhZ2UsIHNvIEkgdGhpbmsgdGhpcyB3b3JrYXJvdW5kIGlzc3VlIDIu DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+PiBQZXIgbXkgdW5kZXJzdG9vZCBzaG91bGQgd2Fp dGluZyBZaW5naGFpIEx1J3MgcGF0Y2hlcyBmb3Iga2lsbGluZw0KPiA+ID4+Pj4gRTgyMF9SRVNF UlZFRF9LRVJOIHRvIGF2b2lkIHRoZSBhbGlnbmVkIHByb2JsZW0uDQo+ID4gPj4+IFtZdV0geWVz LCBpdCBpcyBhIGdyYWNlZnVsIHNvbHV0aW9uLCBidXQgSSBkb24ndCBzZWUgdGhhdCBpbiA0LjE/ DQo+ID4gPj4+IEFuZCB3ZSBlbmNvdW50ZXJlZCBwcm9ibGVtIDMgaW4gb3VyIHRlc3RpbmcgZW52 aXJvbWVudCwgc28gSSB3cm90ZQ0KPiA+ID4+PiBhIHBhdGNoIHRvIGRlYWwgd2l0aCBpdCBmaXJz dC4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGhhbmtzIGEgbG90IQ0KPiA+ID4+Pj4g Sm9leSBMZWUNCj4gPiA+Pj4+DQo+ID4gPj4NCj4gPiA+PiBUaGFua3MgZm9yIHlvdXIgZXhwbGFu YXRpb24sIHRoZW4geW91ciBwYXRjaCBtYWtlcyBzZW5zZSB0byBtZS4NCj4gPiA+Pg0KPiA+ID4+ IFBsZWFzZSBmZWVsIGZyZWUgdG8gYWRkIHRhZzoNCj4gPiA+Pg0KPiA+ID4+IFJldmlld2VkLWJ5 OiBMZWUsIENodW4tWWkgPGpvZXlsaS5rZXJuZWxAZ21haWwuY29tPg0KPiA+ID4NCj4gPiA+IFBh dGNoIHF1ZXVlZCB1cCBmb3IgNC4zLCB0aGFua3MhDQo+ID4gPg0KPiA+IEhpIFJhZmVhbCwNCj4g PiBQbGVhc2UgaGVscCBkcm9wIHRoaXMgcGF0Y2ggZm9yIG5vdywgUUEgaGFzIGZvdW5kIHNvbWUg cHJvYmxlbXMgd2l0aA0KPiA+IHRoaXMgcGF0Y2ggYXBwbGllZCwgd2UncmUgd29ya2luZyBvbiBp dCBub3cuIFNvcnJ5IGZvciBpbmNvbnZlbmllbmNlLg0KPiANCj4gRHJvcHBpbmcsIHRoYW5rcyBm b3IgdGhlIGhlYWRzIHVwIQ0KPiANCkhpLFJhZmVhbCwgSm9leQ0KSSd2ZSBzZW50IG91dCBhbm90 aGVyIHBhdGNoLCBpdCBpcyBiYXNlZCBvbiBKb2V5J3MgDQpvcmlnaW5hbCBwYXRjaCwgYW5kIGl0 IHRyZWF0cyBhbnkgYWRqYWNlbnQgRTgyMF9SQU0vRTgyMF9SRVNFUlZFRF9LRVJOIHJlZ2lvbnMg YXMNCm9uZS4gSW4gdGhpcyB3YXksICBub24tcGFnZS1hbGlnbmVkIHNldHVwX2RhdGEgYWRkcmVz cyB3b3VsZCBub3QgYmUgYWRkZWQgDQp0byBub3NhdmUgcmVnaW9ucywgdGh1cyB3b3JrYXJvdW5k IHRoZSBoaWJlcm5hdGlvbiBmYWlsb3IgbWVudGlvbmVzIGluDQpodHRwczovL2J1Z3ppbGxhLmtl cm5lbC5vcmcvc2hvd19idWcuY2dpP2lkPTk2MTExDQoNClYxIHBhdGNoIGhhcyBhIHByb2JsZW0g dGhhdCwgTk9UIGV2ZXJ5IHBhZ2UgaW4gcGFnZSB6b25lIGhhcyBhIHZhbGlkIG1hcHBpbmcgYWRk cmVzcyAsIHRodXMNCmFjY2Vzc2luZyB0aGVzZSBwYWdlcyB3b3VsZCBjYXVzZSBwcm9ibGVtLiBT byBJIHJld3JpdGUgdGhpcyBwYXRoIGFuZCBzZW5kIG91dCBhbm90aGVyIFYyIHZlcnNpb24uDQpU aGFua3MgZm9yIHlvdXIgdGltZS4NCg0KIFl1DQo+IA0KPiAtLQ0KPiBJIHNwZWFrIG9ubHkgZm9y IG15c2VsZi4NCj4gUmFmYWVsIEouIFd5c29ja2ksIEludGVsIE9wZW4gU291cmNlIFRlY2hub2xv Z3kgQ2VudGVyLg0K -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Chen Yu, On Wed, Jul 22, 2015 at 08:58:11AM +0000, Chen, Yu C wrote: > > > > -----Original Message----- > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net] > > Sent: Wednesday, July 22, 2015 9:04 AM > > To: Chen, Yu C > > Cc: linux-pm@vger.kernel.org; Wysocki, Rafael J; joeyli; Tian, YeX > > Subject: Re: [RFC PATCH] PM / hibernate: make sure each resuming page is > > in current memory zones > > > > On Tuesday, July 21, 2015 09:28:32 AM chenyu5 wrote: > > > On 2015?07?16? 08:30, Rafael J. Wysocki wrote: > > > > On Monday, July 06, 2015 04:37:39 PM joeyli wrote: > > > >> Hi Chen Yu, > > > >> > > > >> On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: > > > >>> Hi, Joey > > > >>> thanks for your reply, > > > >>> > > > >>> On 2015?07?02? 14:19, joeyli wrote: > > > >>>> Hi Chen Yu, > > > >>>> > > > >>>> On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: > > > >>>>> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 > > > >>>>> reserved > > > >>>>> regions") was reverted, because this patch makes resume from > > > >>>>> hibernation on Lenovo x230 unreliable. But reverting may bring > > > >>>>> back the kernel exception firstly reported in former patch. In > > > >>>>> general, there are three problems in current code when resuming > > from hibernation: > > > >>>>> > > > >>>>> 1.Resuming page may also be in second kernel's e820 reserved > > region. > > > >>>>> BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] > > reserved > > > >>>>> this causes kernel exception described in Commit 84c91b7ae07c > > > >>>>> ("PM / hibernate: avoid unsafe pages in e820 reserved regions") > > > >>>>> > > > >>>>> 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in > > > >>>>> e820 reserved regions") is applied to fix problem 1, and if > > > >>>>> E820_RESERVED_KERN regions causes some regions at e820 table > > not > > > >>>>> page aligned, e820_mark_nosave_regions will misjudgment the > > > >>>>> non-page aligned space to be "hole" space and add to nosave > > regions, this causes resuming failed. > > > >>>>> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for > > detail. > > > >>>>> > > > >>>> > > > >>>> Sorry for I am not fully understand why checking pfn_valid could > > > >>>> avoid the above 2. issue? > > > >>>> > > > >>> [Yu] According to e820_mark_nosave_regions, two kinds of e820 > > > >>> regions will be regarded as nosave: > > > >>> a.e820.map holes between each e820entry b.e820entry with > > > >>> (!E820_RAM && !E820_RESERVED_KERN) dmesg in > > > >>> https://bugzilla.kernel.org/show_bug.cgi?id=96111 > > > >>> shows that: > > > >>> > > > >>> BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable > > > >>> reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] > > > >>> usable > > > >>> PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] > > > >>> > > > >>> e820 map was changed by situation a, but it should not be added to > > > >>> nosave list, right? > > > >>> > > > >>> and according to saveable_page, only pages in the zone will be saved: > > > >>> if (page_zone(page_ != zone) > > > >>> return NULL; > > > >>> > > > >>> The function of is_valid_orig_page in this patch treats setup_data > > > >>> as valid page, so I think this workaround issue 2. > > > >>> > > > >>> > > > >>>> Per my understood should waiting Yinghai Lu's patches for killing > > > >>>> E820_RESERVED_KERN to avoid the aligned problem. > > > >>> [Yu] yes, it is a graceful solution, but I don't see that in 4.1? > > > >>> And we encountered problem 3 in our testing enviroment, so I wrote > > > >>> a patch to deal with it first. > > > >>>> > > > >>>> > > > >>>> Thanks a lot! > > > >>>> Joey Lee > > > >>>> > > > >> > > > >> Thanks for your explanation, then your patch makes sense to me. > > > >> > > > >> Please feel free to add tag: > > > >> > > > >> Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> > > > > > > > > Patch queued up for 4.3, thanks! > > > > > > > Hi Rafeal, > > > Please help drop this patch for now, QA has found some problems with > > > this patch applied, we're working on it now. Sorry for inconvenience. > > > > Dropping, thanks for the heads up! > > > Hi,Rafeal, Joey > I've sent out another patch, it is based on Joey's > original patch, and it treats any adjacent E820_RAM/E820_RESERVED_KERN regions as > one. In this way, non-page-aligned setup_data address would not be added > to nosave regions, thus workaround the hibernation failor mentiones in > https://bugzilla.kernel.org/show_bug.cgi?id=96111 > > V1 patch has a problem that, NOT every page in page zone has a valid mapping address , thus > accessing these pages would cause problem. So I rewrite this path and send out another V2 version. > Thanks for your time. > > Yu > > Thanks for your work on this patch, but the E820_RESERVED_KERN will be removed anyhow. So I prefer waiting Yinghai Lu's patch for killing E820_RESERVED_KERN. Regards Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015?07?23? 13:34, joeyli wrote: > Hi Chen Yu, > > On Wed, Jul 22, 2015 at 08:58:11AM +0000, Chen, Yu C wrote: >> >> >>> -----Original Message----- >>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net] >>> Sent: Wednesday, July 22, 2015 9:04 AM >>> To: Chen, Yu C >>> Cc: linux-pm@vger.kernel.org; Wysocki, Rafael J; joeyli; Tian, YeX >>> Subject: Re: [RFC PATCH] PM / hibernate: make sure each resuming page is >>> in current memory zones >>> >>> On Tuesday, July 21, 2015 09:28:32 AM chenyu5 wrote: >>>> On 2015?07?16? 08:30, Rafael J. Wysocki wrote: >>>>> On Monday, July 06, 2015 04:37:39 PM joeyli wrote: >>>>>> Hi Chen Yu, >>>>>> >>>>>> On Thu, Jul 02, 2015 at 04:00:42PM +0800, chenyu5 wrote: >>>>>>> Hi, Joey >>>>>>> thanks for your reply, >>>>>>> >>>>>>> On 2015?07?02? 14:19, joeyli wrote: >>>>>>>> Hi Chen Yu, >>>>>>>> >>>>>>>> On Tue, Jun 30, 2015 at 11:54:28PM +0800, Chen Yu wrote: >>>>>>>>> Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 >>>>>>>>> reserved >>>>>>>>> regions") was reverted, because this patch makes resume from >>>>>>>>> hibernation on Lenovo x230 unreliable. But reverting may bring >>>>>>>>> back the kernel exception firstly reported in former patch. In >>>>>>>>> general, there are three problems in current code when resuming >>> from hibernation: >>>>>>>>> >>>>>>>>> 1.Resuming page may also be in second kernel's e820 reserved >>> region. >>>>>>>>> BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] >>> reserved >>>>>>>>> this causes kernel exception described in Commit 84c91b7ae07c >>>>>>>>> ("PM / hibernate: avoid unsafe pages in e820 reserved regions") >>>>>>>>> >>>>>>>>> 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in >>>>>>>>> e820 reserved regions") is applied to fix problem 1, and if >>>>>>>>> E820_RESERVED_KERN regions causes some regions at e820 table >>> not >>>>>>>>> page aligned, e820_mark_nosave_regions will misjudgment the >>>>>>>>> non-page aligned space to be "hole" space and add to nosave >>> regions, this causes resuming failed. >>>>>>>>> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for >>> detail. >>>>>>>>> >>>>>>>> >>>>>>>> Sorry for I am not fully understand why checking pfn_valid could >>>>>>>> avoid the above 2. issue? >>>>>>>> >>>>>>> [Yu] According to e820_mark_nosave_regions, two kinds of e820 >>>>>>> regions will be regarded as nosave: >>>>>>> a.e820.map holes between each e820entry b.e820entry with >>>>>>> (!E820_RAM && !E820_RESERVED_KERN) dmesg in >>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=96111 >>>>>>> shows that: >>>>>>> >>>>>>> BIOS-e820: [mem 0x000000005baff000-0x00000000d684ffff] usable >>>>>>> reserve setup_data: [mem 0x000000009d3e0018-0x000000009d3f0057] >>>>>>> usable >>>>>>> PM: Registered nosave memory: [mem 0x9d3e0000-0x9d3e0fff] >>>>>>> >>>>>>> e820 map was changed by situation a, but it should not be added to >>>>>>> nosave list, right? >>>>>>> >>>>>>> and according to saveable_page, only pages in the zone will be saved: >>>>>>> if (page_zone(page_ != zone) >>>>>>> return NULL; >>>>>>> >>>>>>> The function of is_valid_orig_page in this patch treats setup_data >>>>>>> as valid page, so I think this workaround issue 2. >>>>>>> >>>>>>> >>>>>>>> Per my understood should waiting Yinghai Lu's patches for killing >>>>>>>> E820_RESERVED_KERN to avoid the aligned problem. >>>>>>> [Yu] yes, it is a graceful solution, but I don't see that in 4.1? >>>>>>> And we encountered problem 3 in our testing enviroment, so I wrote >>>>>>> a patch to deal with it first. >>>>>>>> >>>>>>>> >>>>>>>> Thanks a lot! >>>>>>>> Joey Lee >>>>>>>> >>>>>> >>>>>> Thanks for your explanation, then your patch makes sense to me. >>>>>> >>>>>> Please feel free to add tag: >>>>>> >>>>>> Reviewed-by: Lee, Chun-Yi <joeyli.kernel@gmail.com> >>>>> >>>>> Patch queued up for 4.3, thanks! >>>>> >>>> Hi Rafeal, >>>> Please help drop this patch for now, QA has found some problems with >>>> this patch applied, we're working on it now. Sorry for inconvenience. >>> >>> Dropping, thanks for the heads up! >>> >> Hi,Rafeal, Joey >> I've sent out another patch, it is based on Joey's >> original patch, and it treats any adjacent E820_RAM/E820_RESERVED_KERN regions as >> one. In this way, non-page-aligned setup_data address would not be added >> to nosave regions, thus workaround the hibernation failor mentiones in >> https://bugzilla.kernel.org/show_bug.cgi?id=96111 >> >> V1 patch has a problem that, NOT every page in page zone has a valid mapping address , thus >> accessing these pages would cause problem. So I rewrite this path and send out another V2 version. >> Thanks for your time. >> >> Yu >>> > > Thanks for your work on this patch, but the E820_RESERVED_KERN will be removed > anyhow. So I prefer waiting Yinghai Lu's patch for killing E820_RESERVED_KERN. > OK. I'll wait for Yinghai's patch and yours. Thanks. Yu > > Regards > Joey Lee > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 5235dd4..ebbb995 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -881,6 +881,9 @@ static struct memory_bitmap *forbidden_pages_map; /* Set bits in this map correspond to free page frames. */ static struct memory_bitmap *free_pages_map; +/* Set bits in this map correspond to all valie page frames. */ +static struct memory_bitmap *valid_pages_map; + /* * Each page frame allocated for creating the image is marked by setting the * corresponding bits in forbidden_pages_map and free_pages_map simultaneously @@ -922,6 +925,11 @@ static void swsusp_unset_page_forbidden(struct page *page) memory_bm_clear_bit(forbidden_pages_map, page_to_pfn(page)); } +int swsusp_page_is_valid(struct page *page) +{ + return valid_pages_map ? + memory_bm_test_bit(valid_pages_map, page_to_pfn(page)) : 0; +} /** * mark_nosave_pages - set bits corresponding to the page frames the * contents of which should not be saved in a given bitmap. @@ -955,6 +963,31 @@ static void mark_nosave_pages(struct memory_bitmap *bm) } } +/* mark_valid_pages - set bits corresponding to all page frames */ +static void mark_valid_pages(struct memory_bitmap *bm) +{ + struct zone *zone; + unsigned long pfn, max_zone_pfn; + + for_each_populated_zone(zone) { + max_zone_pfn = zone_end_pfn(zone); + for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++) + if (pfn_valid(pfn)) + mem_bm_set_bit_check(bm, pfn); + } +} + +static bool is_valid_orig_page(unsigned long pfn) +{ + if (!swsusp_page_is_valid(pfn_to_page(pfn))) { + pr_err( + "PM: %#010llx to restored not in current valid memory region\n", + (unsigned long long) pfn << PAGE_SHIFT); + return false; + } else + return true; +} + /** * create_basic_memory_bitmaps - create bitmaps needed for marking page * frames that should not be saved and free page frames. The pointers @@ -965,13 +998,15 @@ static void mark_nosave_pages(struct memory_bitmap *bm) int create_basic_memory_bitmaps(void) { - struct memory_bitmap *bm1, *bm2; + struct memory_bitmap *bm1, *bm2, *bm3; int error = 0; - if (forbidden_pages_map && free_pages_map) + if (forbidden_pages_map && free_pages_map && + valid_pages_map) return 0; else - BUG_ON(forbidden_pages_map || free_pages_map); + BUG_ON(forbidden_pages_map || free_pages_map || + valid_pages_map); bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL); if (!bm1) @@ -989,14 +1024,27 @@ int create_basic_memory_bitmaps(void) if (error) goto Free_second_object; + bm3 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL); + if (!bm3) + goto Free_second_bitmap; + + error = memory_bm_create(bm3, GFP_KERNEL, PG_ANY); + if (error) + goto Free_third_object; + forbidden_pages_map = bm1; free_pages_map = bm2; + valid_pages_map = bm3; mark_nosave_pages(forbidden_pages_map); - + mark_valid_pages(valid_pages_map); pr_debug("PM: Basic memory bitmaps created\n"); return 0; + Free_third_object: + kfree(bm3); + Free_second_bitmap: + memory_bm_free(bm2, PG_UNSAFE_CLEAR); Free_second_object: kfree(bm2); Free_first_bitmap: @@ -1015,19 +1063,24 @@ int create_basic_memory_bitmaps(void) void free_basic_memory_bitmaps(void) { - struct memory_bitmap *bm1, *bm2; + struct memory_bitmap *bm1, *bm2, *bm3; - if (WARN_ON(!(forbidden_pages_map && free_pages_map))) + if (WARN_ON(!(forbidden_pages_map && free_pages_map && + valid_pages_map))) return; bm1 = forbidden_pages_map; bm2 = free_pages_map; + bm3 = valid_pages_map; forbidden_pages_map = NULL; free_pages_map = NULL; + valid_pages_map = NULL; memory_bm_free(bm1, PG_UNSAFE_CLEAR); kfree(bm1); memory_bm_free(bm2, PG_UNSAFE_CLEAR); kfree(bm2); + memory_bm_free(bm3, PG_UNSAFE_CLEAR); + kfree(bm3); pr_debug("PM: Basic memory bitmaps freed\n"); } @@ -2023,7 +2076,7 @@ static int mark_unsafe_pages(struct memory_bitmap *bm) do { pfn = memory_bm_next_pfn(bm); if (likely(pfn != BM_END_OF_MAP)) { - if (likely(pfn_valid(pfn))) + if (likely(pfn_valid(pfn)) && is_valid_orig_page(pfn)) swsusp_set_page_free(pfn_to_page(pfn)); else return -EFAULT; @@ -2053,8 +2106,6 @@ 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"; if (reason) { printk(KERN_ERR "PM: Image mismatch: %s\n", reason); return -EPERM;
Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved regions") was reverted, because this patch makes resume from hibernation on Lenovo x230 unreliable. But reverting may bring back the kernel exception firstly reported in former patch. In general, there are three problems in current code when resuming from hibernation: 1.Resuming page may also be in second kernel's e820 reserved region. BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved this causes kernel exception described in Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved regions") 2.If Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820 reserved regions") is applied to fix problem 1, and if E820_RESERVED_KERN regions causes some regions at e820 table not page aligned, e820_mark_nosave_regions will misjudgment the non-page aligned space to be "hole" space and add to nosave regions, this causes resuming failed. Refer to https://bugzilla.kernel.org/show_bug.cgi?id=96111 for detail. 3.e820 memory map inconsistence. Sometimes resuming system may have larger memory capacity than the one before hibernation. If a strict superset relationship is satisfied, it should be allowed to resume. For example, use case of memory hotplug after hibernation. 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 This patch solves above three problems, by checking whether each page to be restored is strictly subset of current system's available memory zone region. If it is, it's safe to continue, otherwise terminate. Signed-off-by: Chen Yu <yu.c.chen@intel.com> --- kernel/power/snapshot.c | 69 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 9 deletions(-)