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=-6.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 48000C352A3 for ; Mon, 10 Feb 2020 10:45:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFB5520863 for ; Mon, 10 Feb 2020 10:45:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="dyNqMJou" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFB5520863 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 7ECAD6B00E1; Mon, 10 Feb 2020 05:45:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79D166B00E3; Mon, 10 Feb 2020 05:45:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B3AE6B00E4; Mon, 10 Feb 2020 05:45:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 4F7F56B00E1 for ; Mon, 10 Feb 2020 05:45:05 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E47898248047 for ; Mon, 10 Feb 2020 10:45:04 +0000 (UTC) X-FDA: 76473884928.20.alley46_496580495d221 X-HE-Tag: alley46_496580495d221 X-Filterd-Recvd-Size: 7649 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 10:45:04 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id o15so6551056ljg.6 for ; Mon, 10 Feb 2020 02:45:04 -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:content-transfer-encoding:in-reply-to; bh=BNx4VxoH3E26nb5mVtZHenO7uYXaeGKCX3HrnaRRsGM=; b=dyNqMJouR9bWVSssHqRG8taozcRDO+iNHSU5I1D2hgvnseaCXcUMj7tJEUtAlIGBmW AxZh4Q0R04v96UKWjfu8yLKMIHRQvLu0Js6aL7knWYQoNoG7FSTHRUORv3rJNFxyBg5G iye0rRWRcRKxsS7G8NyFXpXBKfA+Mv/IhLBw7/aTdcrd91/yOwhpQgLJTjCAIIeYPxCN bZrsv251OXANlrIb5mbJsOSIMiTfF/J1qwFGyaJQbiB6/IGH1CTCAGNfo/v6F1MGVfpS 2gpPGyA8UjccjX8t9gQO7iQ223Wd0me9uA7WZwx0Gtq586kcBdC5MzPtinBJQGQ8uBH8 I0rg== 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:content-transfer-encoding :in-reply-to; bh=BNx4VxoH3E26nb5mVtZHenO7uYXaeGKCX3HrnaRRsGM=; b=FjKtJF+t+YiyESOtQhDNLe1gyBpUN8JyiMa0PCubY42vpVUbrPvyTJPAw36nP7Sk+l ny00VCwerIGklVvBm67vy841xwygcuJdPmZsq4uCmmSGX9SotWKS40Ur1WLZPXGN9Jyw 9ndiZULrLggFckWv/fJWjV8FhfkxtXMeJ9jnHg2m8LfMG9jL+ljVYSHP05Lv/Gi1ZP8x Cl3WWebnNyeebDVh72QVpn89bbRwsTBkw0I4SURivn83b/ycq8viO6Q9bV4/P2EEbWpW t7fXI/cjJYht5N07NARceN0m/3I7Ww1bRULhgiVoxF7wZcFHQ971LWwQrHhpNiecf0qv dMOQ== X-Gm-Message-State: APjAAAXKLZB3RyGukxSr+Cp3mulhDTzku2xtFWr7lU0rtoxKnEe4Xo1B 1j9Z82+Oa+1W8jzQpO99iQIX3gPHDyM= X-Google-Smtp-Source: APXvYqzyUEuxFAUfEIVcadkslHcmmVVpWoyic/17vJ/VNXRS8askqpbnT9FZG3o3qI5x0Zrl3T7RXg== X-Received: by 2002:a2e:8755:: with SMTP id q21mr541832ljj.156.1581331502847; Mon, 10 Feb 2020 02:45:02 -0800 (PST) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id r9sm6107449lfc.72.2020.02.10.02.45.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Feb 2020 02:45:02 -0800 (PST) Received: by box.localdomain (Postfix, from userid 1000) id 9D0CD100B0A; Mon, 10 Feb 2020 13:45:20 +0300 (+03) Date: Mon, 10 Feb 2020 13:45:20 +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 , Will Deacon , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes , Nathan Chancellor , Florian Weimer Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap(). Message-ID: <20200210104520.cfs2oytkrf5ihd3m@box> References: <20200207201856.46070-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200207201856.46070-1-bgeffon@google.com> Content-Transfer-Encoding: quoted-printable 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, Feb 07, 2020 at 12:18:56PM -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. =A0If a userfaultfd was watchi= ng > the source, it will continue to watch the new mapping. =A0For a mapping > that is shared or not anonymous, MREMAP_DONTUNMAP will cause the > mremap() call to fail. Because MREMAP_DONTUNMAP always results in movin= g > 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 sourc= e. >=20 > 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 worr= y > about VMA permission changes. >=20 > 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 physi= cal > 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 consum= ing > 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." > =A0 =A0 > Signed-off-by: Brian Geffon > --- > include/uapi/linux/mman.h | 5 +- > mm/mremap.c | 98 ++++++++++++++++++++++++++++++--------- > 2 files changed, 80 insertions(+), 23 deletions(-) >=20 > diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h > index fc1a64c3447b..923cc162609c 100644 > --- a/include/uapi/linux/mman.h > +++ b/include/uapi/linux/mman.h > @@ -5,8 +5,9 @@ > #include > #include > =20 > -#define MREMAP_MAYMOVE 1 > -#define MREMAP_FIXED 2 > +#define MREMAP_MAYMOVE 1 > +#define MREMAP_FIXED 2 > +#define MREMAP_DONTUNMAP 4 > =20 > #define OVERCOMMIT_GUESS 0 > #define OVERCOMMIT_ALWAYS 1 > diff --git a/mm/mremap.c b/mm/mremap.c > index 122938dcec15..9f4aa17f178b 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -318,8 +318,8 @@ unsigned long move_page_tables(struct vm_area_struc= t *vma, > static unsigned long move_vma(struct vm_area_struct *vma, > unsigned long old_addr, unsigned long old_len, > unsigned long new_len, unsigned long new_addr, > - bool *locked, struct vm_userfaultfd_ctx *uf, > - struct list_head *uf_unmap) > + bool *locked, unsigned long flags, > + struct vm_userfaultfd_ctx *uf, struct list_head *uf_unmap) > { > struct mm_struct *mm =3D vma->vm_mm; > struct vm_area_struct *new_vma; > @@ -408,11 +408,41 @@ static unsigned long move_vma(struct vm_area_stru= ct *vma, > if (unlikely(vma->vm_flags & VM_PFNMAP)) > untrack_pfn_moved(vma); > =20 > + if (unlikely(!err && (flags & MREMAP_DONTUNMAP))) { > + if (vm_flags & VM_ACCOUNT) { > + /* Always put back VM_ACCOUNT since we won't unmap */ > + vma->vm_flags |=3D VM_ACCOUNT; > + > + vm_acct_memory(vma_pages(new_vma)); > + } > + > + /* > + * locked_vm accounting: if the mapping remained the same size > + * it will have just moved and we don't need to touch locked_vm > + * because we skip the do_unmap. If the mapping shrunk before > + * being moved then the do_unmap on that portion will have > + * adjusted vm_locked. Only if the mapping grows do we need to > + * do something special; the reason is locked_vm only accounts > + * for old_len, but we're now adding new_len - old_len locked > + * bytes to the new mapping. > + */ > + if (new_len > old_len) > + mm->locked_vm +=3D (new_len - old_len) >> PAGE_SHIFT; Hm. How do you enforce that we're not over RLIMIT_MEMLOCK? --=20 Kirill A. Shutemov