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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 0C972C4320A for ; Thu, 12 Aug 2021 18:02:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E544A6101E for ; Thu, 12 Aug 2021 18:02:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236681AbhHLSCd (ORCPT ); Thu, 12 Aug 2021 14:02:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:58740 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235453AbhHLSCb (ORCPT ); Thu, 12 Aug 2021 14:02:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E8CE960FED; Thu, 12 Aug 2021 18:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628791325; bh=SHuQM+8f293Vwgu1Bf0Mq+SZ5B7X8I7/R4G6PeUiInk=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=V3vwAR50GFwnBdbOarqwagm6WuhzDnUThFl/bYs0aCl4BkOVABJU10aoQdVYLBjzP Fou+e6DvAnpAX44FAhDd03cxzdlPWs1XCsGLsX5lUVmMa4jrhTa7T1514dd6n2IGzC XOvSqL9L6N8q0ayOLd/5PyU2vpeItvrJsTl0r+G8uGECXlYOWMg09kERbT5Q8UxLGu ES+aVcZgdXozhIs+hjZ857vWXMxTS9nPggXKtJXpMEoNsESuCoBNHQYxbxAE5UtTOO V8WSqo+Y7y81KBbyMfsY84knZ1/HYAQnjwJdnplM4PUrfpZjls5FYJzy0SFVAiOZtN m4xU5dDmF6qbQ== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 1862527C0054; Thu, 12 Aug 2021 14:02:04 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Thu, 12 Aug 2021 14:02:04 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeefgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedthfehtedtvdetvdetudfgueeuhfdtudegvdelveelfedvteelfffg fedvkeegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1614CA038A7; Thu, 12 Aug 2021 14:02:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-554-g53a5f93b7d-fm-20210809.002-g53a5f93b Mime-Version: 1.0 Message-Id: <9fed831a-b311-4a23-8f3a-eb7ddff9b102@www.fastmail.com> In-Reply-To: <87lf56bllc.fsf@disp2133> References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> Date: Thu, 12 Aug 2021 11:01:36 -0700 From: "Andy Lutomirski" To: "Eric W. Biederman" Cc: "David Hildenbrand" , "Linux Kernel Mailing List" , "Linus Torvalds" , "Andrew Morton" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "H. Peter Anvin" , "Al Viro" , "Alexey Dobriyan" , "Steven Rostedt" , "Peter Zijlstra (Intel)" , "Arnaldo Carvalho de Melo" , "Mark Rutland" , "Alexander Shishkin" , "Jiri Olsa" , "Namhyung Kim" , "Petr Mladek" , "Sergey Senozhatsky" , "Andy Shevchenko" , "Rasmus Villemoes" , "Kees Cook" , "Greg Ungerer" , "Geert Uytterhoeven" , "Mike Rapoport" , "Vlastimil Babka" , "Vincenzo Frascino" , "Chinwen Chang" , "Michel Lespinasse" , "Catalin Marinas" , "Matthew Wilcox (Oracle)" , "Huang Ying" , "Jann Horn" , "Feng Tang" , "Kevin Brodsky" , "Michael Ellerman" , "Shawn Anastasio" , "Steven Price" , "Nicholas Piggin" , "Christian Brauner" , "Jens Axboe" , "Gabriel Krisman Bertazi" , "Peter Xu" , "Suren Baghdasaryan" , "Shakeel Butt" , "Marco Elver" , "Daniel Jordan" , "Nicolas Viennot" , "Thomas Cedeno" , "Collin Fijalkovich" , "Michal Hocko" , "Miklos Szeredi" , "Chengguang Xu" , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-unionfs@vger.kernel.org, "Linux API" , "the arch/x86 maintainers" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org On Thu, Aug 12, 2021, at 10:48 AM, Eric W. Biederman wrote: > "Andy Lutomirski" writes: > I had a blind spot, and Florian Weimer made a very reasonable request. > Apparently userspace for shared libraires uses MAP_PRIVATE. > > So we almost don't care if the library is overwritten. We loose some > efficiency and apparently there are some corner cases like the library > being extended past the end of the exiting file that are problematic. > > Given that MAP_PRIVATE for shared libraries is our strategy for handling > writes to shared libraries perhaps we just need to use MAP_POPULATE or a > new related flag (perhaps MAP_PRIVATE_NOW) that just makes certain that > everything mapped from the executable is guaranteed to be visible from > the time of the mmap, and any changes from the filesystem side after > that are guaranteed to cause a copy on write. > > Once we get that figured out we could consider getting rid of deny-write > entirely. Are all of the CoW bits in good enough shape for this to work without just immediately CoWing the whole file? In principle, write(2) to a file should be able to notice that it needs to CoW some pages, but I doubt that this actually works. --Andy