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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240061 --- 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/snmall= oc/ and was prodding at its use of MADV_FREE together with some in-kernel chang= es 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 wro= te 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 sti= ll, 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 f= ound by vm_fault()" pages there are? > I suspect that this would result in excessive fragmentation of the map en= tries backing the malloc() store. That is certainly a risk. In the case of snmalloc's use of MADV_FREE, thou= gh, it is generally followed by a mmap() MAP_ANON of the same space (possibly m= uch later, when it re-allocates the address space). I assume that these anonym= ous map entries, both arising from mmap() and MADV_FREE's (proposed) vm_object_split()-based changes are subject to simplification when adjacent? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240061-227-zOFWaZVfPR>