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=-12.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 8C091C43216 for ; Thu, 26 Aug 2021 21:47:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 220D260FD8 for ; Thu, 26 Aug 2021 21:47:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 220D260FD8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9A0408D0002; Thu, 26 Aug 2021 17:47:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 951318D0001; Thu, 26 Aug 2021 17:47:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F1138D0002; Thu, 26 Aug 2021 17:47:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id 61EA28D0001 for ; Thu, 26 Aug 2021 17:47:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 03D46180A0D69 for ; Thu, 26 Aug 2021 21:47:16 +0000 (UTC) X-FDA: 78518568072.18.16BB412 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP id AD55B70000A6 for ; Thu, 26 Aug 2021 21:47:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630014435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K0s8bk6QfHD1VaGSzfIqDqYg0K6iJ7Ku0EqSDBa9+yo=; b=SeAtxiH+9rkrguJQBL5t9v2nM0AZw0JxehhzdDRqG4Po10h5yrgiosjoY03uU7IAvtBd2d UN2cDpK5aw1V1ZlBSJ2TU2/6GOPy/EtgmF+PZnqbKYZA6fWWaTtNDs+RZTWDD1kL7HKH0G SbW0SMvajF9MhP6K54TokkVmL8KyIX0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-85-e6Kf3y4-PGGrd8PV5YdlmA-1; Thu, 26 Aug 2021 17:47:12 -0400 X-MC-Unique: e6Kf3y4-PGGrd8PV5YdlmA-1 Received: by mail-wr1-f71.google.com with SMTP id b7-20020a5d4d87000000b001575d1053d2so1300846wru.23 for ; Thu, 26 Aug 2021 14:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=K0s8bk6QfHD1VaGSzfIqDqYg0K6iJ7Ku0EqSDBa9+yo=; b=Ahq4VRFHwzJP2Doc+EqJ/4ewIB8UnEFTtPlIip/LqCBmTR+2Gugax1eoCoPQsmaX9T vjA6Wbc0P7QR3kJBINQkPoJdA6r5d7RGam+mBV6kHtJJ/vYqMjlC97mm6hbn5vUywvzc 7COBp6QehTnIEkndvwKIKQ2zJWm+lm0HGY+QdSXSNyvpHPo2ezMZjk4i6FJegAPJaI4V 7/fgOTj9O5YsaiyI/OWB4Q32iYg9r6mzQGXPhreJRLPR4VxIHJB+HeqJKLimb7cgCLRa OB7VP/sywFtSbxIfk5nj2AfgRnFnortE9H7996aVp7s1pAsQ6iKo952E7uPxbapihPer AJcA== X-Gm-Message-State: AOAM531XyY76DIlsLHYCqlu4KgAZtKWXKbDdyyYhv1ClMG8ck0iyI0Kc Lm+9XM6sokGlOWXW0U1IgfJ2cWL1u+i93AQHoA7nC/ClpTA1mXlZxmy3b290ZklHElqvwnsp62Q tW35lkSDJd7I= X-Received: by 2002:a5d:690a:: with SMTP id t10mr6609888wru.304.1630014430899; Thu, 26 Aug 2021 14:47:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZSDS7ykz6c0cWQQRRV6c/ocWUVA2MbQuhyj4tL0c/EqpuZXrSGG6H7whtDXAvdDs+XQeksw== X-Received: by 2002:a5d:690a:: with SMTP id t10mr6609835wru.304.1630014430662; Thu, 26 Aug 2021 14:47:10 -0700 (PDT) Received: from [192.168.3.132] (p4ff23dec.dip0.t-ipconnect.de. [79.242.61.236]) by smtp.gmail.com with ESMTPSA id q10sm3612286wmq.12.2021.08.26.14.47.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 14:47:10 -0700 (PDT) Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE To: Andy Lutomirski , Linus Torvalds Cc: "Eric W. Biederman" , David Laight , 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-fsdevel@vger.kernel.org, Linux-MM , Florian Weimer , Michael Kerrisk 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> From: David Hildenbrand Organization: Red Hat Message-ID: <0ed69079-9e13-a0f4-776c-1f24faa9daec@redhat.com> Date: Thu, 26 Aug 2021 23:47:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SeAtxiH+; spf=none (imf27.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: AD55B70000A6 X-Stat-Signature: 4awoypenkoxurau6ei19uonirkt9oyun X-HE-Tag: 1630014435-286553 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 26.08.21 19:48, Andy Lutomirski wrote: > On Fri, Aug 13, 2021, at 5:54 PM, Linus Torvalds wrote: >> On Fri, Aug 13, 2021 at 2:49 PM Andy Lutomirski wrot= e: >>> >>> I=E2=80=99ll bite. How about we attack this in the opposite directio= n: remove the deny write mechanism entirely. >> >> I think that would be ok, except I can see somebody relying on it. >> >> It's broken, it's stupid, but we've done that ETXTBUSY for a _loong_ t= ime. >=20 > Someone off-list just pointed something out to me, and I think we shoul= d push harder to remove ETXTBSY. Specifically, we've all been focused on= open() failing with ETXTBSY, and it's easy to make fun of anyone opening= a running program for write when they should be unlinking and replacing = it. >=20 > Alas, Linux's implementation of deny_write_access() is correct^Wabsurd,= and deny_write_access() *also* returns ETXTBSY if the file is open for w= rite. So, in a multithreaded program, one thread does: >=20 > fd =3D open("some exefile", O_RDWR | O_CREAT | O_CLOEXEC); > write(fd, some stuff); >=20 > <--- problem is here >=20 > close(fd); > execve("some exefile"); >=20 > Another thread does: >=20 > fork(); > execve("something else"); >=20 > In between fork and execve, there's another copy of the open file descr= iption, and i_writecount is held, and the execve() fails. Whoops. See, = for example: >=20 > https://github.com/golang/go/issues/22315 >=20 > I propose we get rid of deny_write_access() completely to solve this. >=20 > Getting rid of i_writecount itself seems a bit harder, since a handful = of filesystems use it for clever reasons. >=20 > (OFD locks seem like they might have the same problem. Maybe we should= have a clone() flag to unshare the file table and close close-on-exec th= ings?) >=20 It's not like this issue is new (^2017) or relevant in practice. So no=20 need to hurry IMHO. One step at a time: it might make perfect sense to=20 remove ETXTBSY, but we have to be careful to not break other user space=20 that actually cares about the current behavior in practice. --=20 Thanks, David / dhildenb