Messages in this thread | | | Date | Tue, 7 Oct 2003 12:07:44 -0700 | From | Roland McGrath <> | Subject | Re: [PATCH] dump read-only anonymous memory in core files |
| |
> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |