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 E020AC35242 for ; Tue, 11 Feb 2020 23:32:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F917206D6 for ; Tue, 11 Feb 2020 23:32:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="liMR+ja4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F917206D6 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 51CCC6B0372; Tue, 11 Feb 2020 18:32:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F4036B0373; Tue, 11 Feb 2020 18:32:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 409CB6B0374; Tue, 11 Feb 2020 18:32:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 265AF6B0372 for ; Tue, 11 Feb 2020 18:32:55 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CC592181AC9CC for ; Tue, 11 Feb 2020 23:32:54 +0000 (UTC) X-FDA: 76479448668.23.sink05_8dcfa305d6b4b X-HE-Tag: sink05_8dcfa305d6b4b X-Filterd-Recvd-Size: 4235 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 23:32:54 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id m8so139323edi.13 for ; Tue, 11 Feb 2020 15:32:54 -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=dSs7UqmD5JkZZbHb6Da5Z4JrHfZRP5ftJHQt9uAAdrI=; b=liMR+ja4NzU1aOeqaKl4lbrBoRPtK+iwhpCD3ABdyNXC3IV0OkN3hWEOnv+stwyz0p dLvQVDNXNtPDaA4s61UCJ/3rotRJB/rTr5S8Cf9nj7ULYw81Aw4eW6jcW8FSnkpmkvFd S6jaIPrwapXw4jFnQN3EKyucf6zFOyc2+AAVH3ZF+KkhnTYbaAZHf9l69KVrBBOME6gy /mUhEwIhyx2yeczYKS/Ts9DFICgi9MWfVd6V5YiEbXZNoeczIP9qwGVwnFrqIrj7UhGM TlJlsGQhF7vrtBEFZYIULny/TaQZIx8x7GxfyVcNWvMGsS/sfcOBKF4lPCrnZ6HS/y0D dGCQ== 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=dSs7UqmD5JkZZbHb6Da5Z4JrHfZRP5ftJHQt9uAAdrI=; b=kd1Q6HJwCzLCmpvxBcjTOL33DPk/d3C3SE8P0EYe3dzkKDu+R4xjOu0wztaZYAUad1 ZSHYkvvYXjbmrvSxXY5bwPsPuDJ869fLpKpI7Wh0ckrKWTadyIiovuQj2n6ICTfg2NQv YgnxgIADMaHuNCEs8moGGHsMpLCls703kmM1ETfIHjW5nmGDva0u+DYsG8a6eWnVpM8j xvrSr6xckxhKPQQflmfpEZOZG1u0DdgVH08JPUSMB6CpKeMKLC1s3gjqP9XEYSprNIhs GNEgrHVx8+9G9I7g3wvN35uH2tTKroWZbSlOtFboMf9gahk5LobCQAKD36rC8WiPdmmd Qmwg== X-Gm-Message-State: APjAAAXHScHnAxGA51JM+V5HwoRV/M8COmsWpKZRVe+YW6Pe2hmWBGMY 8S0xFPMxRGJtI5IU7oAaCcw01igAtWJBZ1B/IMDUJg== X-Google-Smtp-Source: APXvYqwMMZEHyNax/K9vt49l37WE+90gfgIcM9+R+CCDjwgdS1qYkAJjiKABPD4lZFkil4hu37IJKAM0KZWO/WJI9NU= X-Received: by 2002:a05:6402:6c7:: with SMTP id n7mr7881480edy.177.1581463973027; Tue, 11 Feb 2020 15:32:53 -0800 (PST) MIME-Version: 1.0 References: <20200207201856.46070-1-bgeffon@google.com> In-Reply-To: From: Brian Geffon Date: Tue, 11 Feb 2020 15:32:26 -0800 Message-ID: Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap(). To: Daniel Colascione 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: 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. Brian