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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 61A14C4320E for ; Fri, 20 Aug 2021 08:46:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DD0196112D for ; Fri, 20 Aug 2021 08:46:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DD0196112D 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 62DCE6B0071; Fri, 20 Aug 2021 04:46:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DDC16B0072; Fri, 20 Aug 2021 04:46:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A6058D0001; Fri, 20 Aug 2021 04:46:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 2F0456B0071 for ; Fri, 20 Aug 2021 04:46:54 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BFA8E183432CE for ; Fri, 20 Aug 2021 08:46:53 +0000 (UTC) X-FDA: 78494828706.27.6A14D7C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 66D4D9000247 for ; Fri, 20 Aug 2021 08:46:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629449212; 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=2HhD3HCRTFvEVqk5yap83SXC5Y82U0v5dcvw39zc4Z4=; b=Od/YVVp56FfGcH2dn6uozq9o/Cas/SG5Va6yzSOuGerU+masdrfaqUSz7BKY6teYgDj+qk 5E+4nk4Oup6r0I3yrSTHmnamClsQqmJw3xobtML9ZnxH/urx2ymxuSQ1mszTDsO5qgBBXQ RMXmJpDWIMf9rv3l/V6SMbEiCeMuqfQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-138-qdTm1ZO6NxSKUgNkHa44mg-1; Fri, 20 Aug 2021 04:46:49 -0400 X-MC-Unique: qdTm1ZO6NxSKUgNkHa44mg-1 Received: by mail-wm1-f71.google.com with SMTP id m13-20020a7bcf2d000000b002e6cd9941a9so4550836wmg.1 for ; Fri, 20 Aug 2021 01:46:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2HhD3HCRTFvEVqk5yap83SXC5Y82U0v5dcvw39zc4Z4=; b=fXIL+g/GG6CSLbEYRCG8+oXvgHB0nOt7TLGYeX23bj+Oqu8qfqsn8NMBPwHBLhbG+K ZJvq1sI8HA6X5o9b1ityaxgy7HzaY7RRExDp+R1CnmaHce6MXNtIAySB90T8BmOyqkj4 RqdBh0NNHGn3K+Dk7YRbcME6QJEr9vPrWsLkXwo+FuvLIqwWFlx7094W90UXCPI2l826 Ot0XP8dGsh5XFYsvYtxGgeI5K929CVtFQ/wpz84dlAYNm6R1K7Hb+hTfZcUUj8YPAlhL JkdLDcEcYzDWeC92R+td5Rbz6mYGTTnxphbRlhmKBhCcBDTJ7lxNLv2jolCIHqNSyrfF JrcA== X-Gm-Message-State: AOAM5324DvnOe1rfnpJejx8/CmkUM/MqxzWLpPSdBaz9Bq8yjr55TH++ BUMX2Cj40AdoLo08qAbnEBTzlHZJMJxJoz1CqIOHTaHzl/Pyl5AGoF/g25RgV//QT2ERiPNi3M2 VoNgzVpAW3KAWUGcejo5e7K+T/cpVmgyeppyTY7vj7MdBaGT9e/RXHzeF4xg= X-Received: by 2002:a1c:3b09:: with SMTP id i9mr2685767wma.62.1629449208445; Fri, 20 Aug 2021 01:46:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytHgubr94As8EiptaA6/T3rm3zShRCHuT1SQpKBWMx/QJTseDVs/BhmrdZPds05dmrZoxc2A== X-Received: by 2002:a1c:3b09:: with SMTP id i9mr2685692wma.62.1629449208132; Fri, 20 Aug 2021 01:46:48 -0700 (PDT) Received: from ?IPv6:2003:d8:2f0a:7f00:fad7:3bc9:69d:31f? (p200300d82f0a7f00fad73bc9069d031f.dip0.t-ipconnect.de. [2003:d8:2f0a:7f00:fad7:3bc9:69d:31f]) by smtp.gmail.com with ESMTPSA id l9sm5187699wrt.95.2021.08.20.01.46.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 01:46:47 -0700 (PDT) To: Linus Torvalds Cc: Linux Kernel Mailing List , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Alexander Viro , Alexey Dobriyan , Steven Rostedt , Peter Zijlstra , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Petr Mladek , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Kees Cook , "Eric W. Biederman" , Greg Ungerer , Geert Uytterhoeven , Mike Rapoport , Vlastimil Babka , Vincenzo Frascino , Chinwen Chang , 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 , Michal Hocko , Miklos Szeredi , Chengguang Xu , =?UTF-8?Q?Christian_K=c3=b6nig?= , Florian Weimer , David Laight , linux-unionfs@vger.kernel.org, Linux API , the arch/x86 maintainers , linux-fsdevel , Linux-MM References: <20210816194840.42769-1-david@redhat.com> <20210816194840.42769-3-david@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 2/7] kernel/fork: factor out replacing the current MM exe_file Message-ID: Date: Fri, 20 Aug 2021 10:46:45 +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 X-Rspamd-Queue-Id: 66D4D9000247 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Od/YVVp5"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam04 X-Stat-Signature: 7fnsxx9b6qqi4yjoqybit6idgk7ks1un X-HE-Tag: 1629449213-668245 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 19.08.21 22:51, Linus Torvalds wrote: > So I like this series. >=20 > However, logically, I think this part in replace_mm_exe_file() no > longer makes sense: >=20 > On Mon, Aug 16, 2021 at 12:50 PM David Hildenbrand w= rote: >> >> + /* Forbid mm->exe_file change if old file still mapped. */ >> + old_exe_file =3D get_mm_exe_file(mm); >> + if (old_exe_file) { >> + mmap_read_lock(mm); >> + for (vma =3D mm->mmap; vma && !ret; vma =3D vma->vm_ne= xt) { >> + if (!vma->vm_file) >> + continue; >> + if (path_equal(&vma->vm_file->f_path, >> + &old_exe_file->f_path)) >> + ret =3D -EBUSY; >> + } >> + mmap_read_unlock(mm); >> + fput(old_exe_file); >> + if (ret) >> + return ret; >> + } >=20 > and should just be removed. >=20 > NOTE! I think it makes sense within the context of this patch (where > you just move code around), but that it should then be removed in the > next patch that does that "always deny write access to current MM > exe_file" thing. >=20 > I just quoted it in the context of this patch, since the next patch > doesn't actually show this code any more. >=20 > In the *old* model - where the ETXTBUSY was about the mmap() of the > file - the above tests make sense. >=20 > But in the new model, walking the mappings just doesn't seem to be a > sensible operation any more. The mappings simply aren't what ETXTBUSY > is about in the new world order, and so doing that mapping walk seems > nonsensical. >=20 > Hmm? I think this is somewhat another kind of "stop user space trying to do stupid things" thingy, not necessarily glued to ETXTBUSY: don't allow replacing exe_file if that very file is still mapped and consequently eventually still in use by the application. I don't think it necessarily has many things to do with ETXTBUSY: we only check if there is a VMA mapping that file, not that it's a VM_DENYWRITE mapping. That code originates from commit 4229fb1dc6843c49a14bb098719f8a696cdc44f8 Author: Konstantin Khlebnikov Date: Wed Jul 11 14:02:11 2012 -0700 c/r: prctl: less paranoid prctl_set_mm_exe_file() "no other files mapped" requirement from my previous patch (c/r: prc= tl: update prctl_set_mm_exe_file() after mm->num_exe_file_vmas removal) = is too paranoid, it forbids operation even if there mapped one shared-anon = vma. =20 Let's check that current mm->exe_file already unmapped, in this case exe_file symlink already outdated and its changing is reasonable. The statement "exe_file symlink already outdated and its changing is reasonable" somewhat makes sense. Long story short, I think this check somehow makes a bit of sense, but we wouldn't lose too much if we drop it -- just another sanity check. Your call :) --=20 Thanks, David / dhildenb