Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4016660ybv; Mon, 10 Feb 2020 10:39:51 -0800 (PST) X-Google-Smtp-Source: APXvYqwjiIDK0crUx0yPgWOHA8JJugF79DBgmNLdVW8405PeZkppgXm2wKPazzDYpDd9VtxTNyRT X-Received: by 2002:a9d:811:: with SMTP id 17mr2129697oty.369.1581359991301; Mon, 10 Feb 2020 10:39:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581359991; cv=none; d=google.com; s=arc-20160816; b=wTi+Io9eB9qSaSCKQgRqNcwcRhqLLVng5V9sDHgSwkQCZQbVu7cr4DgzssGepWakSt QYPFXpcDH9ae2GlXJiaTIIJdJHBkj1Hno5IoJ+HhD9BbJg3QyjWQ1zrdcOibmmq8oBu3 EsacDfmbN5PSURfPmOIxsQNks60F7k3TeR6GA90N816VfNrf/i4ud9cx/ykrehsVoco0 JpJEACpSMdarY5TkkCnNNoHSgxeJ1KRgtlFUorfxOJMCM6Kkfq/6VIg63ShMxBPdDlHg zTtzJ7pXvPcQearGNGAM69H5Q3q8lAQ3h5516rvgyd6O1XhrWv+PQdYc0luv8OlaavdV JPaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jlsflCZJObjYz2WQ+bj1XSIApVgJryVHpJZHj+0ZcAs=; b=laGDcBalP/YQ+fYUmz0obTP5P1Ht9ggXTOOTZJzcWBRH6+ROo2nMLTmJ5c8eIHOAwX H4WeeKjqE4k+GXHM/A2kLDlENu8Ey6BnYk0kc9mXRIHJ+TJzB1wi/KtLPfdPeUjXjgWR xi7drOU7LUcsy0+tlqv0e/XRRhXn/cXjPZJ1IPNJp/zSm7MHpczt98Vytgs+dmojzoJk b8F5Vzc9IZNBzgpBWj/Q2aQDwe4Y0wCFtCteISQH261qSEJ2yw/wBgvLHrCKwBCNyn5V 3HbjpPPypGy5Gdh5rG4AJEhmaZjU19T5guhsCrw5PU19ecxYRo2MzICVZ6vKhMLkV/mO 5drw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="H2shC/nd"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s9si463740oij.78.2020.02.10.10.39.39; Mon, 10 Feb 2020 10:39:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="H2shC/nd"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727797AbgBJSj2 (ORCPT + 99 others); Mon, 10 Feb 2020 13:39:28 -0500 Received: from mail-ed1-f67.google.com ([209.85.208.67]:42395 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727008AbgBJSj2 (ORCPT ); Mon, 10 Feb 2020 13:39:28 -0500 Received: by mail-ed1-f67.google.com with SMTP id e10so1510838edv.9 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=gQGxmgRoPwfttqrzyghjsBuE5sFxRKp3s8x1hew21OL1c/Woe8dCpHVDZHwJkFjbEd FyleLaUIXw4HgVKKEyiKEt/8JVx2NDAUe19RDnx+cGOCQ8cxBH+8mLek1/oHs6sspv6l f7TS1MSwrwRaiWASRxIXTS/tuLqonc6delleqFs3Qwk4sjYwajSjIcSOVm8FmzqleZnR 6BSfJJqA6gG6yCIRnI2TSF0HbJ94xCX/WQyEmQYA9qI+NfTnr0YDopB3wwE0JmZJFwnG 8U7sF8thGAcX1nt+FpFRb9LZb+HnBBCg6pLtT+aUh0F9Kk2h6cau9lA4g9mw+OiOwySp Y1xw== X-Gm-Message-State: APjAAAUHiRYE+hdB+wFgmUYqNAGU2KbYL8yciYtJ/baBQ58b/5mfY2oI bbyczhHmP4Z13buuRijAZJnmRW3/c/GByl5qUK1EMQ== 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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? >