Date: Mon, 26 Aug 2019 20:16:37 +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-zOFWaZVfPR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240061-227@https.bugs.freebsd.org/bugzilla/> References: <bug-240061-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240061 --- Comment #4 from Nathaniel Filardo <nwf20@cl.cam.ac.uk> --- > Out of curiosity, how did you come to notice this behaviour? We've been studying heap temporal safety and wanted to make fairly strong assertions about the contents of, and aliasing of access to, heap memory. (If you'd like to have a longer conversation, my inbox is open. :) ) In particular, I've been looking deeply at https://github.com/microsoft/snmalloc/ and was prodding at its use of MADV_FREE together with some in-kernel changes that crawls the address space. I was hoping to have this crawler remove MADV_FREE'd pages as junk, but then wondered what would happen and then wrote a test and here we are. Incidentally, I *think* this behaviour implies that pages existing before fork()s will be held by the system (possibly paged out 'n all that, but still, present), even if all of their shadowing pages have been copied up, so long as the shadowing objects continue to exist? I don't suppose there's an easy, even if expensive, way to measure how many such "referenced but would never be found by vm_fault()" pages there are? > I suspect that this would result in excessive fragmentation of the map entries backing the malloc() store. That is certainly a risk. In the case of snmalloc's use of MADV_FREE, though, it is generally followed by a mmap() MAP_ANON of the same space (possibly much later, when it re-allocates the address space). I assume that these anonymous map entries, both arising from mmap() and MADV_FREE's (proposed) vm_object_split()-based changes are subject to simplification when adjacent? -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240061-227-zOFWaZVfPR>