Re: [2.6.21.1] resume doesn't run suspended kernel?

[Nigel Cunningham <nigel@nigel.suspend2.net>]

Hi.

On Mon, 2007-06-04 at 13:02 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > They are already.
> > > 
> > > ...but will that place still be safe when we use other version of
> > > kernel?
> > 
> > They'll be in the image too, won't they? Failing that, the information
> > could be stored in the image header.
> > 
> > > Anyway, pagedirs are on the safe place, right? That means that we
> > > swsusp should no longer clash with page allocation debugging... 
> > 
> > You mean DEBUG_PAGEALLOC? That can be overcome easily - I have code in
> > current Suspend2 that works with DEBUG_PAGEALLOC. I handle the page
> > fault, mapping the page and setting a flag in the fault handler to tell
> > the atomic copy code to unmap the page again once it has been copied.
> 
> I meant debug_pagealloc, but no, I do not think we want to make page
> fault handler more complex. Switching to 1:1 mapping tables should be
> enough.
> 								Pavel

@@ -311,6 +315,20 @@ fastcall void __kprobes do_page_fault(struct pt_regs *regs,
 
 	si_code = SEGV_MAPERR;
 
+	/* During a Suspend2 atomic copy, with DEBUG_SLAB, we will
+	 * get page faults where slab has been unmapped. Map them
+	 * temporarily and set the variable that tells Suspend2 to
+	 * unmap afterwards.
+	 */
+
+	if (unlikely(suspend2_running && !suspend2_faulted)) {
+		struct page *page = NULL;
+		suspend2_faulted = 1;
+		page = virt_to_page(address);
+		kernel_map_pages(page, 1, 1);
+		return;
+	}
+
 	/*
 	 * We fault-in kernel-space virtual memory on-demand. The
 	 * 'reference' page table is init_mm.pgd.

Regards,

Nigel

Attachment: signature.asc
Description: This is a digitally signed message part