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.4 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,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 EDA30C32771 for ; Tue, 28 Jan 2020 01:36:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A5A472467C for ; Tue, 28 Jan 2020 01:36:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YQuxh3Nb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5A472467C 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 5044D6B0003; Mon, 27 Jan 2020 20:36:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 48C3D6B0006; Mon, 27 Jan 2020 20:36:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3548F6B0007; Mon, 27 Jan 2020 20:36:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 1BBF56B0003 for ; Mon, 27 Jan 2020 20:36:09 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id C7DD78248047 for ; Tue, 28 Jan 2020 01:36:08 +0000 (UTC) X-FDA: 76425327216.17.tin80_359b577f60f58 X-HE-Tag: tin80_359b577f60f58 X-Filterd-Recvd-Size: 5533 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jan 2020 01:36:08 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id m13so12907901edb.6 for ; Mon, 27 Jan 2020 17:36:08 -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=Crjx+5QQrEucO7G7mPXgmMnWuJ0oteWXeZ4JlN/M8ds=; b=YQuxh3NbOiJ+dKXmeUU1Z/8VEVIPsnSsHTDZJAjufPbsfkmO0zDnRXF0ifSfj9He4G jBGiR66Cn37+5/XyWFlEtwhWQDTmnC4F7/YbLmJ8/6RaOlWn4iVsO+3IGlW4ZjsWaVql 1bUyIxB9ZZKoeB2XnEvqaPfd+D+9rzYMmoRiSGgeOMOZmaMeeJ8u1Ul970EWbwVXML18 oHUn3+ruk3TNRCHRpiGQvn8ggab7wE9mDH4/w72NTGDeegdT3NreH9sZnbF2+M2q1z7V zbN7raOB40jkg3tQVnU+4gLmL/TFdoKI4i0u3GxgZGWAZbtI0c7K8tEgfRS3FPUB658W qgFg== 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=Crjx+5QQrEucO7G7mPXgmMnWuJ0oteWXeZ4JlN/M8ds=; b=SvaRMcWDX/ttdJNYfu+LxGObX/S1gDpRiYsWGZU0ZO+4NTA06bJr0Wx1k7rNwc5PIl RgMbE/tlXJz7d+8cqDUCMTUag0Ga6mG9ad+5+Gd3QqmCiK9yeaLfoWgROGOTX18Nw/gK uBkEGq/LClAiUnI9zv0YmiYJj+j4Z6cjFxzKkvEmuj1+E734FiqZGiO3BdlQI35xz6P+ sR3qua6x6PPd7EjYhGygvdIBxWdMq50h6KRHenlV8/rcDtW+0RBDreEk7btVYLKF8Hba BUPL0NEyY4rnP7QgSXbNyiCdnyaYkmbkTWnlcXrTlNfS1CrY42DcIGg9SzPsfoiYhX2o 7cIA== X-Gm-Message-State: APjAAAXpFvu/K4i/AuIcUtc8I1L+klfGq0TYtHi9FFM83Bxtu/IjcMIs kjLEvyMmQO8UtLKj8j46+G+7ScruUgfmDHCy/7RcZQ== X-Google-Smtp-Source: APXvYqyV4VLuvnfJLGmY7TZvmrf57n5fPdUEkoVlX8bSQLT0/E1hgAPOBzOsZPbWzr2GZLSCZkLSu+O7SBtsHf0flr8= X-Received: by 2002:a17:906:4e01:: with SMTP id z1mr1206542eju.46.1580175366815; Mon, 27 Jan 2020 17:36:06 -0800 (PST) MIME-Version: 1.0 References: <20200123014627.71720-1-bgeffon@google.com> <20200124190625.257659-1-bgeffon@google.com> <20200126220650.i4lwljpvohpgvsi2@box> In-Reply-To: <20200126220650.i4lwljpvohpgvsi2@box> From: Brian Geffon Date: Mon, 27 Jan 2020 17:35:40 -0800 Message-ID: Subject: Re: [PATCH v2] mm: Add MREMAP_DONTUNMAP to mremap(). To: "Kirill A. Shutemov" Cc: Andrew Morton , "Michael S . Tsirkin" , Arnd Bergmann , LKML , linux-mm , linux-api@vger.kernel.org, Andy Lutomirski , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes 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: Hi Kirill, Thanks for taking the time to look at this. I'll update the wording to make it clear that MREMAP_FIXED is required with MREMAP_DONTUNMAP. Regarding rmap, you're completely right I'm going to roll a new patch which will call unlink_anon_vmas() to make sure the rmap is correct, I'll also explicitly check that the vma is anonymous and not shared returning EINVAL if not, how does that sound? Brian On Sun, Jan 26, 2020 at 2:06 PM Kirill A. Shutemov wrote: > > 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