From owner-freebsd-bugs@freebsd.org Mon Aug 26 20:16:37 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 704F0E417A for ; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 46HNZF2R9Rz3NHB for ; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 51BCBE4179; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 517B7E4178 for ; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46HNZF1SDyz3NH8 for ; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0FC2EB795 for ; Mon, 26 Aug 2019 20:16:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7QKGaAL052141 for ; Mon, 26 Aug 2019 20:16:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7QKGa6u052140 for bugs@FreeBSD.org; Mon, 26 Aug 2019 20:16:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 240061] MADV_FREE rewinds time to before fork() Date: Mon, 26 Aug 2019 20:16:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nwf20@cl.cam.ac.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 20:16:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240061 --- Comment #4 from Nathaniel Filardo --- > 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.=