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=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 58F62C761A0 for ; Wed, 19 Feb 2020 23:23:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1AD8E207FD for ; Wed, 19 Feb 2020 23:23:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Cfn8V0Yc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1AD8E207FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A4AF56B0005; Wed, 19 Feb 2020 18:23:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FB4A6B0006; Wed, 19 Feb 2020 18:23:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C3D86B0007; Wed, 19 Feb 2020 18:23:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id 716146B0005 for ; Wed, 19 Feb 2020 18:23:14 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 26B278248D51 for ; Wed, 19 Feb 2020 23:23:14 +0000 (UTC) X-FDA: 76508454708.09.nut93_5662552631107 X-HE-Tag: nut93_5662552631107 X-Filterd-Recvd-Size: 5698 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Feb 2020 23:23:13 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id 84so873991pfy.6 for ; Wed, 19 Feb 2020 15:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=CeoKC7hzC6I62gTM+Mhw7YfGVER9ZVRo7JdMhdNPmSk=; b=Cfn8V0YciBTXAuwpgcp6rJ1RRQWQ8YESs/k45IyinbQAtZtOm98ulE4qaSflYZd7sl eywfyM46Y1P2n8SwDF1GidyApN6qI1rhNuAY1yOun/lyTDQAOc8V9KBHQNDycGniKiW7 1QHYPhY6hl/Sk8H2xcKnPJZVeHhhbF7evCksyKBIr6HqXEixSVZ3z1yqy7XkNHTVLnoP 9uEdM0hEDV5JdaI/2ncUBOfVa2z30hrBiLFjkfSBt4i4k0DIfGfQbQWzjYdjj5aoMRCF 5mVtod5EaNgCVF9gs2hmSmUyzTnVkTtBN9Vi903hiwAzzycvFDblncNDP14qPOmIeOVh jgrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=CeoKC7hzC6I62gTM+Mhw7YfGVER9ZVRo7JdMhdNPmSk=; b=T298a+YpAE4tdH1kA2a8NVNPDskgL4fsJ9roVidonpTT+zn0ckOUrdys4vtrI838jF pxtWsZJNysVLPSxoZ8Ed7aDq2dFhBtXqsmbiYvxC8R8yyYrwzZNDUpqCBmx08BbQb2J8 evBqUt+vK9bu6ZXn8YUyRTH+P//u/u/eFFVIDXao+Z/6gwwFAfs5sj/e067aZYs/alge h71VXTMyqz7Bh2PKmsOAGDonKg9crlO6xLB8BMy5Ozh4E/4Hkdc8EWTfcl13F8ijIUAZ a40JxpDX1WXdQO94vW6HpBu/B2hPPiWC8Mo8NCtQSexgUlHJPnukQAZT+5QjIMwi+t7T 9mgw== X-Gm-Message-State: APjAAAXOLwR9gT+bGWsvalUmBnA4VDJ8MsP/bp9kvYqnlkGCE2H9DkpD ckJe/N1sOKeBnuoMglU+Iu4= X-Google-Smtp-Source: APXvYqzYVMfv/pKmDoOIvzEuKdD1kuiEsw68gFp/0c+G+WPa4VaIT2FxxcWcsbL/yOnHnbRu8/lxVQ== X-Received: by 2002:aa7:820d:: with SMTP id k13mr30135749pfi.10.1582154592037; Wed, 19 Feb 2020 15:23:12 -0800 (PST) Received: from google.com ([2620:15c:211:1:3e01:2939:5992:52da]) by smtp.gmail.com with ESMTPSA id w11sm717199pfn.4.2020.02.19.15.23.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2020 15:23:11 -0800 (PST) Date: Wed, 19 Feb 2020 15:23:09 -0800 From: Minchan Kim 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 , Joel Fernandes , Yu Zhao , Jesse Barnes , Florian Weimer , "Kirill A . Shutemov" Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). Message-ID: <20200219232309.GB148976@google.com> References: <20200218173221.237674-1-bgeffon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200218173221.237674-1-bgeffon@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Feb 18, 2020 at 09:32:20AM -0800, Brian Geffon wrote: > When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is > set, the source mapping will not be removed. The remap operation > will be performed as it would have been normally by moving over the > page tables to the new mapping. The old vma will have any locked > flags cleared, have no pagetables, and any userfaultfds that were > watching that range will continue watching it. >=20 > For a mapping that is shared or not anonymous, MREMAP_DONTUNMAP will ca= use > the mremap() call to fail. Because MREMAP_DONTUNMAP always results in m= oving > 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." >=20 > v5 -> v6: > - Code cleanup suggested by Kirill. >=20 > v4 -> v5: > - Correct commit message to more accurately reflect the behavior. > - Clear VM_LOCKED and VM_LOCKEDONFAULT on the old vma. > =A0 =A0 > Signed-off-by: Brian Geffon Description and implemenation looks clean/sane for me. Reviewed-by: Minchan Kim When I review the patch, it seems to be broken with lots of "=3D20", not sure it's my mail client problem or yours. Anyway, please double check it. Thanks.