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=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 9541CC35247 for ; Sun, 26 Jan 2020 22:06:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 36EFB206F0 for ; Sun, 26 Jan 2020 22:06:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="vd7wN7va" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36EFB206F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8286E6B0003; Sun, 26 Jan 2020 17:06:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B1976B0006; Sun, 26 Jan 2020 17:06:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67A016B0007; Sun, 26 Jan 2020 17:06:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 4D3886B0003 for ; Sun, 26 Jan 2020 17:06:48 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 015EE180AD804 for ; Sun, 26 Jan 2020 22:06:47 +0000 (UTC) X-FDA: 76421170896.05.crown27_3b4ada57e1d3d X-HE-Tag: crown27_3b4ada57e1d3d X-Filterd-Recvd-Size: 5347 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Sun, 26 Jan 2020 22:06:47 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id z18so4907160lfe.2 for ; Sun, 26 Jan 2020 14:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bIjpqXTvBSR6objHCm0IzTR/hQ3TPrKkme7EJy7SinQ=; b=vd7wN7vaZJfsftvGGeIdYEwGAd4ISoPUjH4z/airo4c26P52SSKuDuY4RS0FCTd3jk KGJuozw/CRaeDQ8RBJpp+oWUfc2eDnUbiMFkXFrBXbs5ojteYSba/dGN1A/1KxD1aEzs kwJfOZOp2vtTZ1sI5xIYQJlNEmUxEGX6JXv4Xurm4zHypuUTquU8mvoaBx/394qcnVUj RzzbO3aM80carMr02Nqzb6oeiw1Uu4+S5GWqP8R0NK6qJX9IlkQ0sONrEey8uSOh9ukr a/5FajX0UzsqgSnvcxbbzkeC25sud1T/2dcmQXy0fbovFOy/mw4wm/rc/xExEVA6kt85 nmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=bIjpqXTvBSR6objHCm0IzTR/hQ3TPrKkme7EJy7SinQ=; b=RUh+bnRK2bbYhV79OhBuea3RLE6g/xHAjAgFbggb5lR2Htckl0oUYbU/C7VHNASCgX h2aXuJha1ROQ6rZIJYAIZsjtCmRxwiRJ8HDMasis48Pey6mu8D1zmZMl+a6D3YveVJ0y nv8DJ10iPVPpQl/dNSQB6mm4ZCLX+xeyVP0vBD7eMMAUGsJ+cgu1Q58cCAN3GBhKeT4S IZQEdhhLeDlTToNSbvcEsiMNQfPujecVEnN4ACZxjfIaFGrQCeXV4z4yBcvVq26P9fvX o0IN2bhDAKYE9+SpVaoKsQZ1SF5yT0XtZEwySBNnyPLrz4yqdQ6t1LG9WkisnrOxKv8E E0Kw== X-Gm-Message-State: APjAAAWbUhPXr2iuxC8NIh7EdZWuxa6Zj5rtfT5vQROiu+raiS0Ln3sb yzgpnked5i/e6NTSkuyxz3ts2Q== X-Google-Smtp-Source: APXvYqzcewzG3j/TNt2F5XioQ+wUekZmF3eUnjfjLtEYPRrWC1YWX5O7aKsWt9YIO7SAizSUaGlpNQ== X-Received: by 2002:a19:4855:: with SMTP id v82mr6199593lfa.197.1580076405722; Sun, 26 Jan 2020 14:06:45 -0800 (PST) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id w20sm7129060ljo.33.2020.01.26.14.06.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jan 2020 14:06:44 -0800 (PST) Received: by box.localdomain (Postfix, from userid 1000) id 0082B100301; Mon, 27 Jan 2020 01:06:50 +0300 (+03) Date: Mon, 27 Jan 2020 01:06:50 +0300 From: "Kirill A. Shutemov" To: Brian Geffon Cc: Andrew Morton , "Michael S . Tsirkin" , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Andy Lutomirski , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes Subject: Re: [PATCH v2] mm: Add MREMAP_DONTUNMAP to mremap(). Message-ID: <20200126220650.i4lwljpvohpgvsi2@box> References: <20200123014627.71720-1-bgeffon@google.com> <20200124190625.257659-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200124190625.257659-1-bgeffon@google.com> 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 Fri, Jan 24, 2020 at 11:06:25AM -0800, Brian Geffon wrote: > When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is > set, the source mapping will not be removed. Instead it will be > cleared as if a brand new anonymous, private mapping had been created > atomically as part of the mremap() call. If a userfaultfd was watching > the source, it will continue to watch the new mapping. For a mapping > that is shared or not anonymous, MREMAP_DONTUNMAP will cause the > mremap() call to fail. MREMAP_DONTUNMAP implies that MREMAP_FIXED is > also used. Implies? From code it looks like it requires MREMAP_FIXED. And MREMAP_FIXED requires MREMAP_MAYMOVE. That's strange flag chaining. I don't really see need in such dependencies. It maybe indeed implied, not requied. > The final result is two equally sized VMAs where the > destination contains the PTEs of the source. Could you clarify rmap situation here? How the rmap hierarchy will look like before and after the operation. Can the new VMA merge with the old one? Sounds fishy to me. > 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." -- Kirill A. Shutemov