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,URIBL_BLOCKED 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 44D5AC4338F for ; Sat, 14 Aug 2021 00:49:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 13CFA610F7 for ; Sat, 14 Aug 2021 00:49:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235938AbhHNAuL (ORCPT ); Fri, 13 Aug 2021 20:50:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:56286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235870AbhHNAuL (ORCPT ); Fri, 13 Aug 2021 20:50:11 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8238260FBF; Sat, 14 Aug 2021 00:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628902183; bh=GbEcyKahqLyZSn3fvAE19yQmc43heTDUyKcIa187qpk=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=kb8q3ES/OlUeFnGwm2nZ6coTdpkegt4bvJhthqi9fPoDOkqV/BAKtCt2Wo9LceHL8 Xh20AAtd62BZyXezDObdVgMrdeIPR8EuPm2juAo8G537k0XDJW3oGtscPimgMilKOC uRgp0VaLAVymgtfXCdIAi5TNg4tlXd8hc6pc0EZEn21ZWww/0HI7wkr68PXh5ZFQbY FB93iMq9GwF0BLAqcIaiXPXC/m4w2qXfzcno9V3xfnp2S4U3/YoziI+iZbrQQiMTHO Rnjc6vqW0IgsdhYgO9jOZEzcDM1EO8KF3QQdZ62Zc5mYJxEVQVjnhIqERap0Hkr+Fp Jelj35wMNsqcA== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id A065727C005B; Fri, 13 Aug 2021 20:49:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Fri, 13 Aug 2021 20:49:41 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeeigdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedvleehjeejvefhuddtgeegffdtjedtffegveethedvgfejieevieeu feevuedvteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17914A038A7; Fri, 13 Aug 2021 20:49:40 -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: In-Reply-To: References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> <87eeay8pqx.fsf@disp2133> <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> Date: Fri, 13 Aug 2021 17:49:19 -0700 From: "Andy Lutomirski" To: "Linus Torvalds" , "Eric W. Biederman" Cc: "David Laight" , "David Hildenbrand" , "Linux Kernel Mailing List" , "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-MM , "Florian Weimer" , "Michael Kerrisk" Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org On Fri, Aug 13, 2021, at 5:31 PM, Linus Torvalds wrote: > On Fri, Aug 13, 2021 at 10:18 AM Eric W. Biederman > wrote: > > > > Florian Weimer, would it be possible to get glibc's ld.so implementa= tion to use > > MAP_SHARED? Just so people reading the code know what to expect of = the > > kernel? As far as I can tell there is not a practical difference > > between a read-only MAP_PRIVATE and a read-only MAP_SHARED. >=20 > There's a huge difference. >=20 > For one, you actually don't necessarily want read-only. Doing COW on > library images is quite common for things like relocation etc (you'd > _hope_ everything is PC-relative, but no) >=20 > So no. Never EVER use MAP_SHARED unless you literally expect to have > two different mappings that need to be kept in sync and one writes the= > other. >=20 > I'll just repeat: stop arguing about this case. If somebody writes to > a busy library, THAT IS A FUNDAMENTAL BUG, and nobody sane should care= > at all about it apart from the "you get what you deserve". >=20 > What's next? Do you think glibc should also map every byte in the user= > address space so that user programs don't get SIGSEGV when they have > wild pointers? >=20 > Again - that's a user BUG and trying to "work around" a wild pointer > is a worse fix than the problem it tries to fix. >=20 > The exact same thing is true for shared library (or executable) > mappings. Trying to work around people writing to them is *worse* than= > the bug of doing so. >=20 > Stop this completely inane discussion already. >=20 I=E2=80=99ll bite. How about we attack this in the opposite direction: = remove the deny write mechanism entirely. In my life, I=E2=80=99ve encountered -ETXTBUSY intermittently, and it in= variably means that I somehow failed to finish killing a program fast en= ough for whatever random rebuild I=E2=80=99m doing to succeed. It=E2=80=99= s at best erratic =E2=80=94 it only applies for static binaries, and it = has never once saved me from a problem I care about. If the program I=E2= =80=99m recompiling crashes, I don=E2=80=99t care =E2=80=94 it=E2=80=99s= probably already part way through dying from an unrelated fatal signal.= What actually happens is that I see -ETXTBUSY, think =E2=80=9Cwait, th= is isn=E2=80=99t Windows, why are there file sharing rules,=E2=80=9D the= n think =E2=80=9Cwait, Linux has *one* half baked file sharing rule,=E2=80= =9D and go on with my life. [0] Seriously, can we deprecate and remove the whole thing? [0] we have mandatory locks, too. Sigh.