From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 423EFC35254 for ; Wed, 19 Feb 2020 20:39:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F0CFD24670 for ; Wed, 19 Feb 2020 20:39:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="NxlUqyv+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0CFD24670 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 856906B0005; Wed, 19 Feb 2020 15:39:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 806E76B0006; Wed, 19 Feb 2020 15:39:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F4D46B0007; Wed, 19 Feb 2020 15:39:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 5771C6B0005 for ; Wed, 19 Feb 2020 15:39:58 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0F2AA2494 for ; Wed, 19 Feb 2020 20:39:58 +0000 (UTC) X-FDA: 76508043276.03.fight66_74151b70fca0b X-HE-Tag: fight66_74151b70fca0b X-Filterd-Recvd-Size: 3734 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 20:39:57 +0000 (UTC) Received: from X1 (nat-ab2241.sltdut.senawave.net [162.218.216.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5B8F4207FD; Wed, 19 Feb 2020 20:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582144796; bh=gj9va7+1ssiR0Xq4OizFiIrAex7E8V70tSOCZY9+oDI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NxlUqyv+fP3skS7WtpxyG29P3a790L+lksyrIFK4+YwGWx7ELvnqgppw4cSVAdA+t MGDVjrnS6IyRW0LUTw5spQTy9SaK15ZgXVEQXfBX2oYS5YBhHKcOjM4RPUuP8cO2vl 2nQVih708J1LGBOrXgqsSrBP0q7zvzeWunk8YrGs= Date: Wed, 19 Feb 2020 12:39:55 -0800 From: Andrew Morton To: Brian Geffon Cc: "Michael S . Tsirkin" , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Andy Lutomirski , Will Deacon , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes , Florian Weimer , "Kirill A . Shutemov" , lokeshgidra@google.com Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). Message-Id: <20200219123955.dc97c43524d6e6ab92722650@linux-foundation.org> In-Reply-To: <20200218173221.237674-1-bgeffon@google.com> References: <20200218173221.237674-1-bgeffon@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 18 Feb 2020 09:32:20 -0800 Brian Geffon wrote: > When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is > set, the source mapping will not be removed. The remap operation > will be performed as it would have been normally by moving over the > page tables to the new mapping. The old vma will have any locked > flags cleared, have no pagetables, and any userfaultfds that were > watching that range will continue watching it. > > For a mapping that is shared or not anonymous, MREMAP_DONTUNMAP will cause > the mremap() call to fail. Because MREMAP_DONTUNMAP always results in moving > a VMA you MUST use the MREMAP_MAYMOVE flag. The final result is two > equally sized VMAs where the destination contains the PTEs of the source. > > We hope to use this in Chrome OS where with userfaultfd we could write > an anonymous mapping to disk without having to STOP the process or worry > about VMA permission changes. > > This feature also has a use case in Android, Lokesh Gidra has said > that "As part of using userfaultfd for GC, We'll have to move the physical > pages of the java heap to a separate location. For this purpose mremap > will be used. Without the MREMAP_DONTUNMAP flag, when I mremap the java > heap, its virtual mapping will be removed as well. Therefore, we'll > require performing mmap immediately after. This is not only time consuming > but also opens a time window where a native thread may call mmap and > reserve the java heap's address range for its own usage. This flag > solves the problem." Thanks. We're a bit thin on review activity on this one. Has Lokesh been able to review and preferably test the code? Are you able to identify other potential users? perhaps even glibc?