-mm swsusp: fix highmem handling
Subsystems (2)
Hi!
Swsusp was not restoring highmem properly. I did not find a nice place where to restore it, through, so it went to swsusp_free.
I'm not sure why you are saving state before save_processor_state. swsusp_arch_resume will overwrite this, anyway. Is it to make something balanced?
Pavel
kernel/power/swsusp.c +4 -1
@@ -656,6 +652,10 @@free_suspend_pagedir_zone (zone, p); }free_pages (p, pagedir_order); +#ifdef CONFIG_HIGHMEM +printk ("Restoring highmem\n" ); +restore_highmem (); +#endif }
@@ -890,7 +890,6 @@ {int error;local_irq_disable (); -save_processor_state (); error =swsusp_arch_resume ();restore_processor_state ();local_irq_enable ();
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Quoted 2 lines · Pavel Machek
Swsusp was not restoring highmem properly. I did not find a nice place where to restore it, through, so it went to
swsusp_free.
That's too late, and will be called if suspend failed, to clean up any allocated memory. The proper place seems to be in swsusp_resume().
Quoted 3 lines
I'm not sure why you are saving state before
save_processor_state.swsusp_arch_resumewill overwrite this, anyway. Is it to make something balanced?
Yes, so it matches the calls in swsusp_suspend() - Previously there was a hack that did kernel_fpu_end() after calling save_processor_state(), to pass in_atomic() checks. By restoring the state after we've snapshotted on suspend prevents this from being a problem.
In general, if we assume that save_processor_state() does anything to the CPU, besides just benign register saving, we have to make sure that it's put into the same state on resume before we restore state..
Pat
Hi!
Quoted 4 lines
Quoted 3 lines
I'm not sure why you are saving state before
save_processor_state.swsusp_arch_resumewill overwrite this, anyway. Is it to make something balanced?
Quoted 8 lines
Yes, so it matches the calls in
swsusp_suspend()- Previously there was a hack that didkernel_fpu_end()after callingsave_processor_state(), to passin_atomic()checks. By restoring the state after we've snapshotted on suspend prevents this from being a problem.In general, if we assume that
save_processor_state()does anything to the CPU, besides just benign register saving, we have to make sure that it's put into the same state on resume before we restore state..
Perhaps comment is needed there? "state saved by this is ignored, but save_processor_state changes preempt count"?
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
Quoted 6 lines
Swsusp was not restoring highmem properly. I did not find a nice place where to restore it, through, so it went to
swsusp_free.I'm not sure why you are saving state before
save_processor_state.swsusp_arch_resumewill overwrite this, anyway. Is it to make something balanced?
On your suggestion (sorry, I do not have it nearby) I tried moving restore_highmem into swsusp_resume, and it crashed. I'll try moving it around.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!