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 C9036C35242 for ; Tue, 11 Feb 2020 23:53:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62233206DA for ; Tue, 11 Feb 2020 23:53:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="H7/LO54H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62233206DA 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 D71636B0377; Tue, 11 Feb 2020 18:53:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D22716B0379; Tue, 11 Feb 2020 18:53:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C38626B037A; Tue, 11 Feb 2020 18:53:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id AC1D66B0377 for ; Tue, 11 Feb 2020 18:53:41 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 66671181AC553 for ; Tue, 11 Feb 2020 23:53:41 +0000 (UTC) X-FDA: 76479501042.24.bee48_20294c4182361 X-HE-Tag: bee48_20294c4182361 X-Filterd-Recvd-Size: 4770 Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 23:53:40 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id 66so94419otd.9 for ; Tue, 11 Feb 2020 15:53:40 -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=8pO1XQac3lRtY1M/28swyaSfh/76yG4K/A1KWDVLQMc=; b=H7/LO54HPXlaugVHdCUKWXQWNaqDJGRL9AP74RA+bD/0uYm1aIgRD9AZUMJv5rbHXO wa2TRAmOzpCukoY1O7GbT8ai4CWrjPZM3itJtBIsp3Nn3isaCmPTcimOh2zz+sayYYhJ A/CkBQVrCxAm4LLiWttL/NpJabvPU8I5ONb7moY9nbbT8qlyDkVHUdA5qm6HTF3muSjT EdcgHRgAbwNx/xFkJITYP94FV5vyTTADVzqHbeU8z9TOQvYPhWjTGm2cR6juMJADbRVu 1NoyZrnwbUSziuV8uMcwwujUEXiZt5lnnObwVAKMTTAe1OIQFmSgpbUu5o1D36oy9RPz nNmw== 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=8pO1XQac3lRtY1M/28swyaSfh/76yG4K/A1KWDVLQMc=; b=KCZFudzA4cZwc7vJfAYtKWTEebTBvQ1tnVOktUMBT1UaVZ5Ps3xNtab1mMCkSsJF2j qvTYUfT0IYZ3iOfjyFj14hTSlvYR1/mzzvNt0K4oZVbHgHZjVkNcG9llm8j1iTYxFUrO m33adSvVIXOVT5VYRvO1sydbl0Uyj5PpnIMXG0QLAyCAT6vD1jqZK0VTN6Pv07qfqId7 dWkEAhVXYivv6+p09CqtSWFHSM5rQi6H5XO8R3J7yeOL+DEyeXDoYCmhrBi+NZEbbIyK hALLeL2lzX/TOQr+c9hUBS4NKYyrORHQ7Anxms3o75gnlnQsRaK52dPXLBxnUXNaL3Bb PZvA== X-Gm-Message-State: APjAAAX6jVtHU5pLxmv4fXXUklIyPakXJnOuKZX4CEDR4AQv9/6EAOVe NKWZubE2TUTKPYVuUTkTXUsdD3QMwSuXYFSYRVwqNQ== X-Google-Smtp-Source: APXvYqzsMv9hCvtLadRhB6LojTFq/xvtSEK1cMs76x7vatIdsmihFP0CQRxvF63yk9gOA14rSXjWir+Ykd+lS5oH4XY= X-Received: by 2002:a9d:34c:: with SMTP id 70mr138640otv.174.1581465219846; Tue, 11 Feb 2020 15:53:39 -0800 (PST) MIME-Version: 1.0 References: <20200207201856.46070-1-bgeffon@google.com> In-Reply-To: From: Daniel Colascione Date: Tue, 11 Feb 2020 15:53:03 -0800 Message-ID: Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap(). To: Brian Geffon Cc: Andrew Morton , "Michael S . Tsirkin" , Arnd Bergmann , linux-kernel , linux-mm , Linux API , 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: On Tue, Feb 11, 2020 at 3:32 PM Brian Geffon wrote: > > Hi Daniel, > > > What about making the > > left-behind mapping PROT_NONE? This way, we'll still solve the > > address-space race in Lokesh's use case (because even a PROT_NONE > > mapping reserves address space) but won't incur any additional commit > > until someone calls mprotect(PROT_WRITE) on the left-behind mapping. > > This limits the usefulness of the feature IMO and really is too > specific to that one use case, suppose you want to snapshot a memory > region to disk without having to stop a thread you can > mremap(MREMAP_DONTUNMAP) it to another location and safely write it to > disk knowing the faulting thread will be stopped and you can handle it > later if it was registered with userfaultfd, if we were to also change > it to PROT_NONE that thread would see a SEGV. There are other examples > where you can possibly use this flag instead of VM_UFFD_WP, but > changing the protections of the mapping prevents you from being able > to do this without a funny signal handler dance. We seem to have identified two use cases which require contradictory things. We can handle this with an option. Maybe the new region's protection bits should be specified in the flags argument. The most general API would accept any set of mmap flags to apply to the left-behind region, but it's probably hard to squeeze that functionality into the existing API.