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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,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 2CB8CC35240 for ; Thu, 30 Jan 2020 10:12:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C25DE206F0 for ; Thu, 30 Jan 2020 10:12:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="UGpunH0f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C25DE206F0 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 488786B0332; Thu, 30 Jan 2020 05:12:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 438DF6B0333; Thu, 30 Jan 2020 05:12:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32A5A6B0334; Thu, 30 Jan 2020 05:12:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 190066B0332 for ; Thu, 30 Jan 2020 05:12:15 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AD7428248047 for ; Thu, 30 Jan 2020 10:12:14 +0000 (UTC) X-FDA: 76433885388.17.rule53_138c3f5744409 X-HE-Tag: rule53_138c3f5744409 X-Filterd-Recvd-Size: 4681 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2020 10:12:14 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B091B206D5; Thu, 30 Jan 2020 10:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580379133; bh=P9h3/Bn/eSdl3ZWgp0VveGQkiQrefKB9XBTyKjeDoOU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UGpunH0fs3194+uliHqPn4YZ2qcxfggN5Fnih63Cr4LzINmDuXU5FKyXBHbI2h58v XKQqlp5J9a2fMtK23kis7NWl7LHYOrVRsZG8MDuDaQAxM1CdiUR7H2sVdsEK2VtnYM jTIWHwaFeUXyLoM2qZHNgBruUVDtYHwedNjFfpSo= Date: Thu, 30 Jan 2020 10:12:07 +0000 From: Will Deacon 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 , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes , Nathan Chancellor Subject: Re: [PATCH v3] mm: Add MREMAP_DONTUNMAP to mremap(). Message-ID: <20200130101207.GB1532@willie-the-truck> References: <20200123014627.71720-1-bgeffon@google.com> <20200127053056.213679-1-bgeffon@google.com> <20200128152641.GA29776@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200128152641.GA29776@willie-the-truck> 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, Jan 28, 2020 at 03:26:41PM +0000, Will Deacon wrote: > On Sun, Jan 26, 2020 at 09:30: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 watc= hing > > the source, it will continue to watch the new mapping. =A0For a mappi= ng > > that is shared or not anonymous, MREMAP_DONTUNMAP will cause the > > mremap() call to fail. MREMAP_DONTUNMAP requires that MREMAP_FIXED is > > also used. The final result is two equally sized VMAs where the > > destination contains the PTEs of the source. > > =A0 =A0 > > We hope to use this in Chrome OS where with userfaultfd we could writ= e > > an anonymous mapping to disk without having to STOP the process or wo= rry > > about VMA permission changes. > > =A0 =A0 > > 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 phy= sical > > pages of the java heap to a separate location. For this purpose mrema= p > > will be used. Without the MREMAP_DONTUNMAP flag, when I mremap the ja= va > > heap, its virtual mapping will be removed as well. Therefore, we'll > > require performing mmap immediately after. This is not only time cons= uming > > 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 > Hmm, this sounds like you're dealing with a multi-threaded environment, > yet your change only supports private mappings. How does that work? Sorry, this was badly worded. I was trying to understand how the GC is implememented, and whether everything was part of the same process or if things like memfds or something else were being used to share memory. Hav= ing spoken to Brian off-list, it's all one process... > It's also worrying because, with two private mappings of the same anony= mous > memory live simultaneously, you run the risk of hitting D-cache aliasin= g > issues on some architectures and losing coherency between them as a res= ult > (even in a single-threaded scenario). Is userspace just supposed to dea= l > with this, or should we be enforcing SHMLBA alignment? ... and this was me completely misreading the patch. The old mapping is still torn down, but then replaced with a new private mapping rather than being unmapped. However, looks like there are some issues handling shared mappings with this patch (and possibly mlock()?), so I'll wait for a new spin. Will