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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 12694C5ACC4 for ; Wed, 19 Feb 2020 21:38:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8E822465D for ; Wed, 19 Feb 2020 21:38:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZEuMXL1F" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8E822465D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A37E6B007D; Wed, 19 Feb 2020 16:38:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 679646B007E; Wed, 19 Feb 2020 16:38:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 590646B0080; Wed, 19 Feb 2020 16:38:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 413626B007D for ; Wed, 19 Feb 2020 16:38:31 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0E1CE181AEF1E for ; Wed, 19 Feb 2020 21:38:31 +0000 (UTC) X-FDA: 76508190822.22.floor72_2d362ebda4e40 X-HE-Tag: floor72_2d362ebda4e40 X-Filterd-Recvd-Size: 5262 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 21:38:30 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id i11so2239882ioi.12 for ; Wed, 19 Feb 2020 13:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BpJxLBHatawnfc/YTxNMD/ucEUM4syoJPqlp+g1Kz8Q=; b=ZEuMXL1FtfM73aI3r2twzf1ImxMIVuXVXsNvfr/Xv2L9cj6yOITb2an36KFoQYK665 IV5F52dUV5ZV+lgSd5AxnM2CTVBpgWlaDa0WZx2ZxgX8eaW0ikLCNZfem6s5mEZPCoUJ 4H+YQ6ZApf5Kd3lltfN9JAkMKrRcyK4JH4wrIfOmnuxwy8gqGBuCB16vuIgfg9e5PKpR gY5avyjLUFyc4drTwAq7AJGse85GPvxZ61qNJnaDh2YRGX1+lBWg20/gwJAns6dRr5+S 0agFIbGbeSsK62DYfOdfqnEGWiKwnWpyaNVl854LdFQEOCfi+OTXPcq7Q81IGPPz7YFm c+ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BpJxLBHatawnfc/YTxNMD/ucEUM4syoJPqlp+g1Kz8Q=; b=EPpaBo8fBqZ90wEoXtXycUnnabmiuacVTFC1AeZYcJiLFbhz+iHjHkDAolDZVzcF0O pQ7Y4SpRkxyKxBZfMzbqS0MHI2LmPuzTl4JCSUznAyVzvuXFY8lTgmVFL68e+TC3jvib kKGJUU0bVxZTo2bdyEA8RpEkaxV03SXNFmA3smrYxjsz1ZGYpQuWA+wVm6wLH0mDdIaG cTi9agLgfv9S7G10eJhc4VQhyzjLWNTNIA43/PGptnFGXQjna9jYHZNaMKHHmGrVUfaw i7nd2NBEpJWtIR27Vhg4rzFWGu9HD4ptVRkufzckC0UPwvOKDvCcyJPzp1k9fJYpKEbu eaqg== X-Gm-Message-State: APjAAAUy4byQ+0USbL+vxogTG/OXt7s1zYieaJSEKB5wgxRTVG8n5kqm f3oF955GuRLgfFqk1nq/DVxkbNUpi3+ckjBcjYreWg== X-Google-Smtp-Source: APXvYqwS2+y+j0s1eJlgR262ndskG+GNgdkwNc6r3zFLCDHDsMtkOVp/1i9VaZZGb4LIbmoe909gUhg90CJigN/88MM= X-Received: by 2002:a02:780f:: with SMTP id p15mr22552578jac.91.1582148309586; Wed, 19 Feb 2020 13:38:29 -0800 (PST) MIME-Version: 1.0 References: <20200218173221.237674-1-bgeffon@google.com> <20200219123955.dc97c43524d6e6ab92722650@linux-foundation.org> In-Reply-To: <20200219123955.dc97c43524d6e6ab92722650@linux-foundation.org> From: Lokesh Gidra Date: Wed, 19 Feb 2020 13:38:18 -0800 Message-ID: Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). To: Andrew Morton Cc: Brian Geffon , "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" Content-Type: text/plain; charset="UTF-8" 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: I've validated the change, that it works for me, through manual testing. The android runtime changes will follow shortly. Tested-by: Lokesh Gidra On Wed, Feb 19, 2020 at 12:39 PM Andrew Morton wrote: > > 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?