Date: Fri, 23 Aug 2019 20:46:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 240061] MADV_FREE rewinds time to before fork() Message-ID: <bug-240061-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240061 Bug ID: 240061 Summary: MADV_FREE rewinds time to before fork() Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: nwf20@cl.cam.ac.uk MADV_FREE simply cleans pages associated with the current object backing the advisee region so that the act of page reclaimation will remove it if needed. If there is no shadowed object, this is fine: if the page is removed, it will be demand-zeroed, and if it isn't removed, it will be as it was before MADV_FREE. In the case there is a shadowed object (i.e., these pages are CoW; say, they were mapped before fork()), however, if the page is removed, it will not be demand zeroed: it will be copied up from the shadowed object. It is therefore possible to selectively rewind time to before fork() and expose whatever information was in these pages. (I have a test program that demonstrates the effect, but as it relies on inducing memory pressure, it is rude for a test suite; it would be nice if there were a synthetic way to cause the page reclaim subsystem to run even without true memory pressure.) #1851 makes somewhat oblique reference to an issue with MADV_FREE and I presume that it is this behavior that is being commented upon, but it's hard to say for sure. Perhaps this behavior was indeed eliminated in 1997, but it's back now. In any case, I *believe*, not being very familiar with the VM subsystem, that vm_map_madvise() needs to... consider MADV_FREE a modify_map=true operation and... for each map entry within the advisee region, call vm_object_split() and then release the backing object... then call pmap_advise() and vm_object_madvise() on this new object. There may well be a better way to do this; it may, in fact, be desirable to treat MADV_FREE as if it were mmap()-ing a new entry and new object when the advisee object is OBJT_DEFAULT or OBJT_SWAP; I am less sure what MADV_FREE's semantics should be if it's OBJT_VNODE, for example. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240061-227>