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 9A758C35254 for ; Mon, 10 Feb 2020 18:39:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5796820656 for ; Mon, 10 Feb 2020 18:39:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="H2shC/nd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5796820656 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 D3CF26B0147; Mon, 10 Feb 2020 13:39:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CED526B0148; Mon, 10 Feb 2020 13:39:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2A406B0149; Mon, 10 Feb 2020 13:39:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0124.hostedemail.com [216.40.44.124]) by kanga.kvack.org (Postfix) with ESMTP id AA4CB6B0147 for ; Mon, 10 Feb 2020 13:39:27 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 67B9140EE for ; Mon, 10 Feb 2020 18:39:27 +0000 (UTC) X-FDA: 76475080374.13.rock15_8cb46e1624937 X-HE-Tag: rock15_8cb46e1624937 X-Filterd-Recvd-Size: 5149 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 18:39:26 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id p3so1521426edx.7 for ; Mon, 10 Feb 2020 10:39:26 -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=jlsflCZJObjYz2WQ+bj1XSIApVgJryVHpJZHj+0ZcAs=; b=H2shC/nd3zFW54NxtxygSOrpF6OwRFEDTka0iPLEjvdmPLu7I1VoTylWyDE9d2D+qI EaHAStTYKnt2CD1l2Zz+cfM7QiO704trJ+peNsxgkBU3FEKzUlKxB2pt9YPxjtMp+lQ3 rnpI5yCYwGvVC7zvtAVwkF3zQXwf0bEOEgmKhfH1OevTWXAJ++HYzjbCnQHcU5j0LKci 9IGm+2E1QRYL7K/vb5LVHmZWy5bKbDQGsTpQLpdGIrL/D+RcQ0N9sq9087whnjF34ypn fO5r5TfVrAOv/CMJMV4Ij0zQVkGrCJL741Pz0LDu5acNaVb6v1TT5bi1S7LkXEAvEhY7 L19A== 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=jlsflCZJObjYz2WQ+bj1XSIApVgJryVHpJZHj+0ZcAs=; b=CfDhub/fpvVyscP0TnUa4ExqxrHhwjlVJhmVuOv+gzGclEOyyWTRUfREiIChu1rk9O Lbr6SBgm9/tPZknV3lcdNHJvVkh93N8qXrIVxJMPs+QAMwIx4RV+dCwAVxrlERhv6B8t KFGHiDV2b/KozpmeVpnZqkScZWajP3QH5cObMRd6UN1gbznQ8AgnxbIIPS5hEoYzQF2A 5g9K7jxLtJrUFSEhj6zsGU2ASAR7YHuWJuu2WauKoFOKsNXX7Nif2mHSXLMJBMF4aZgY vR08E6GKy/39o9Vmw0bjCO+eYzUlUr42MsPzDPS+jyJDgtXvOq7XjgATBIBCmlJ8kQyc BVqQ== X-Gm-Message-State: APjAAAUdfoaP686I/2Naaulc1g6rLaSB8VtRf+UgwyjBLIgEkeBIQLUN HwUKFWVvTz1OL+SD7ZWQnDawD+lL/YUzsTSoqjVlNQ== X-Google-Smtp-Source: APXvYqxgm95mync8C8GByW2W2TIAYK9hKbNNty/1Wj/xekWtRBxXp0AvW0aop3onKwfYvOCHSXt1Nf6K7areZr5SZIc= X-Received: by 2002:a17:906:b208:: with SMTP id p8mr2527452ejz.191.1581359965172; Mon, 10 Feb 2020 10:39:25 -0800 (PST) MIME-Version: 1.0 References: <20200207201856.46070-1-bgeffon@google.com> <20200209172140.aa60488e10e0408c4f74f11b@linux-foundation.org> In-Reply-To: <20200209172140.aa60488e10e0408c4f74f11b@linux-foundation.org> From: Brian Geffon Date: Mon, 10 Feb 2020 10:38:58 -0800 Message-ID: Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap(). To: Andrew Morton Cc: "Michael S . Tsirkin" , Arnd Bergmann , LKML , linux-mm , linux-api@vger.kernel.org, Andy Lutomirski , Will Deacon , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes , Nathan Chancellor , 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: Thank you Andrew. I'll get working on some self-tests. Brian On Sun, Feb 9, 2020 at 5:21 PM Andrew Morton wrote: > > On Fri, 7 Feb 2020 12:18:56 -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. 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." > > This seems useful and reasonably mature, so I'll queue it for > additional testing and shall await review feedback. > > Could we please get some self-test code for this feature in > tools/testing/selftests/vm? Perhaps in userfaultfd.c? >