Messages in this thread |  | | | From | "Rafael J. Wysocki" <> | | Subject | Re: [PATCH 2/4] swsusp: clean up resume error path | | Date | Tue, 18 Oct 2005 11:17:26 +0200 |
| |
Hi,
On Tuesday, 18 of October 2005 01:47, Pavel Machek wrote: > Hi! > > > The following patch removes an incorrect call to restore_highmem() from > > the resume error path (there's no saved highmem in that case) and makes > > swsusp touch the softlockup watchdog if there's no error (currently it only > > touches the watchdog if an error occurs). > > > > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> > > > > Index: linux-2.6.14-rc4-mm1/kernel/power/swsusp.c > > =================================================================== > > --- linux-2.6.14-rc4-mm1.orig/kernel/power/swsusp.c 2005-10-17 23:28:34.000000000 +0200 > > +++ linux-2.6.14-rc4-mm1/kernel/power/swsusp.c 2005-10-17 23:28:47.000000000 +0200 > > @@ -628,7 +629,6 @@ > > */ > > swsusp_free(); > > restore_processor_state(); > > - restore_highmem(); > > touch_softlockup_watchdog(); > > device_power_up(); > > local_irq_enable(); > > I don't like this one. restore_highmem() does freeing of allocated > pages. If swsusp_arch_suspend() fails in specific way, I suspect it > could leak highmem.
The pages to be freed are only allocated in suspend_prepare_image() (now swsusp_save()), which is on suspend, and this is the resume error path.
The boot kernel that performs the resume does not save highmem, so it need not and IMO it should not call restore_highmem() in the error path (if nothing more, it's misleading). OTOH if the resume succeeds, restore_highmem() will be called from swsusp_suspend().
Gretings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |