Re: [RFC v3][PATCH 5/9] Memory managemnet (restore)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Dave Hansen
Date: Thursday, September 4, 2008 - 11:08 am

On Thu, 2008-09-04 at 04:04 -0400, Oren Laadan wrote:

This needs to go into a header.


Typo in the filename there ^^.


Wouldn't it just be better to save the checkpoint image in the format
that the syscall takes in the first place?

...

This looks much better than what was being used before.  Nice!


Do you find it any easier to read this as:

	nr = npages;
	if (nr > pgarr->nleft)
		nr = pgarr->nleft;

?


The void cast is unnecessary, right?


I'm having some difficulty parsing this function.  Could we
s/data/contents/ in the function name?  It also looks like addrs is
being used like an array here.  Can we use it explicitly that way?  I'd
also like to see it called vaddr or something explicit about what kinds
of addresses they are.


"cr_vma_writable" is a question to me.  This needs to be
"cr_vma_make_writable" or something to indicate that it is modifying the
vma.


Kill the unlikely(), please.  It's unnecessary and tends to make things
slower when not used correctly.  Can you please check all the future
patches and make sure that you don't accidentally introduce these later?


Is this to fixup the same things that setup_arg_pages() uses it for?  We
should probably consolidate those calls somehow.  


Looking at this code, I can now tell that we need to be more explicit
about what nr_pages is.  Is it the nr_pages that the vma spans,
contains, maps....??  Why do we need to check it here?


The english here is a bit funky.  I think this needs to be
cr_vma_read_page_addrs().  The other way makes it sound like you're
reading the "page's addr", meaning a singular page.  Same for data.


Where did this sucker get allocated?  This is going to be a bit
difficult to audit since it isn't allocated and freed (or released) at
the same level.  Seems like it would be much nicer if it was allocated
at the beginning of this function.


Ugh.  Is this a security hole?  What if the user was not allowed to
write to the file being mmap()'d by this VMA?  Is this a window where
someone could come in and (using ptrace or something similar) write to
the file?

We copy into the process address space all the time when not in its
context explicitly.  


Man, that's hard to parse.  Could you break that up a little bit to make
it easier to read?


I'd probably just make a local vm_start to make these all consistent and
do all the ugly casting in one place.


Why the heck is this here?  Isn't this a fresh mm?  We shouldn't have to
do this unless we had a VMA here previously.  Maybe it would be more
efficient to do this when tearing down the old vmas.


The other approach would be to do something more analogous to exec():
create the entire new mm and switch to it in the end. 

-- Dave

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC v3][PATCH 0/9] Kernel based checkpoint/restart, Oren Laadan, (Thu Sep 4, 12:57 am)
[RFC v3][PATCH 4/9] Memory management (dump), Oren Laadan, (Thu Sep 4, 1:03 am)
[RFC v3][PATCH 5/9] Memory managemnet (restore), Oren Laadan, (Thu Sep 4, 1:04 am)
[RFC v3][PATCH 8/9] File descriprtors (dump), Oren Laadan, (Thu Sep 4, 1:05 am)
[RFC v3][PATCH 9/9] File descriprtors (restore), Oren Laadan, (Thu Sep 4, 1:06 am)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Louis Rilling, (Thu Sep 4, 2:47 am)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Oren Laadan, (Thu Sep 4, 7:43 am)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Dave Hansen, (Thu Sep 4, 8:01 am)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Dave Hansen, (Thu Sep 4, 11:08 am)
Re: [RFC v3][PATCH 4/9] Memory management (dump), Dave Hansen, (Thu Sep 4, 11:25 am)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Dave Hansen, (Thu Sep 4, 11:41 am)
Re: [RFC v3][PATCH 4/9] Memory management (dump), Oren Laadan, (Sat Sep 6, 6:54 pm)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Oren Laadan, (Sat Sep 6, 8:09 pm)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Oren Laadan, (Sat Sep 6, 9:52 pm)
Re: [RFC v3][PATCH 4/9] Memory management (dump), Dave Hansen, (Mon Sep 8, 8:55 am)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Dave Hansen, (Mon Sep 8, 9:49 am)
Re: [RFC v3][PATCH 8/9] File descriprtors (dump), Dave Hansen, (Mon Sep 8, 9:57 am)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Oren Laadan, (Mon Sep 8, 11:01 pm)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Dave Hansen, (Wed Sep 10, 2:42 pm)
Cleanups for: [PATCH 5/9] Memory managemnet (restore), Dave Hansen, (Wed Sep 10, 3:00 pm)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Oren Laadan, (Thu Sep 11, 12:37 am)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Serge E. Hallyn, (Thu Sep 11, 8:38 am)
Re: [RFC v3][PATCH 5/9] Memory managemnet (restore), Dave Hansen, (Fri Sep 12, 9:34 am)