Re: [PATCH] dump read-only anonymous memory in core files

[Roland McGrath]

> 
> What about shared mappings (that test should be VM_MAYSHARE)?
> 
> My inclination would be to not dump them if they are backed by a file, 
> even if the mmap is writable.

That sounds reasonable to me (perhaps modulo the shmfs issue).  I intended
my patch not to omit any vmas that were dumped before, so I didn't consider
omitting any writable areas.  (I don't really understand the difference
between VM_MAYSHARE and VM_SHARED, so I might be assuming something wrong
when saying you are right.)

> Also, the VM_WRITE test should possibly be VM_MAYWRITE, since the thing
> could have been mprotect()'ed. Alternatively, we could really add a "this
> mapping has been writable" flag (a kind of "sticky VM_WRITE" bit). It's
> only mprotect that can do this, anyway.

Actually the ideal would be "this mapping has been written to" (or might
have been, i.e. it at least was writable in a pte, if not actually dirty).
Then if you mmap some pages PROT_READ|PROT_WRITE, and then mprotect them
PROT_READ before ever touching them, you don't dump those pages just as you
wouldn't dump always-read-only pages.  (If you had that, you could apply it
to anonymous mappings as well and omit all zero-fill pages.)  Ideally this
would dump PROT_NONE pages that have been written in the past as well,
which is ruled out by the VM_READ test at the top of maydump.  Despite the
comment, it looks to me like dump_write's use of get_user_pages will make
it work, so it could be a VM_MAYREAD check. 


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/