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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 8C3B7C4338F for ; Thu, 19 Aug 2021 20:58:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 30AFF61029 for ; Thu, 19 Aug 2021 20:58:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 30AFF61029 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CCC108D0001; Thu, 19 Aug 2021 16:58:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7C966B0071; Thu, 19 Aug 2021 16:58:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B92C98D0001; Thu, 19 Aug 2021 16:58:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 9F2196B006C for ; Thu, 19 Aug 2021 16:58:45 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3529129DFD for ; Thu, 19 Aug 2021 20:58:45 +0000 (UTC) X-FDA: 78493044210.37.2992888 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf06.hostedemail.com (Postfix) with ESMTP id E2519801A89C for ; Thu, 19 Aug 2021 20:58:44 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id gt38so15427294ejc.13 for ; Thu, 19 Aug 2021 13:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RJyUMpRvCKY0Vh89D3w3gONjiQnSaoV/zmqyDYmDpUA=; b=Y+pU8j9vQaWTxEhQ0j0tkQUmizFhaaD+mBD4UKDchtCcNJDPjhu50XdOkmR7wRhVkU sO/ZAyNE37DjaIrX3Jupm5Lmzorw4l3UwqrPdvdUzj38oBpjeDPsJPwAdFT5IzBfsdoc aflzICp2BeWzdnFJvaqwcQw0cXI2edPGK5Q7U= 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=RJyUMpRvCKY0Vh89D3w3gONjiQnSaoV/zmqyDYmDpUA=; b=i7LG/UbsB0pyLpnausJ7uXuBb1zCxzgo+ylDuiS1oHJW2DGG6+VjNw7v5f7s1icFtr OR1JDDQ7IcSX5ZLTBPHTqs0DaKyWAd23Tbv7UDvMg/QK6+Qq+WFmCE9VlOC0ZrVxBGq5 kgEyvBPLUZi06oDM+Au+Slllqosyt0s5PtzoG7mFEJBrEcFyA4LMBB60/eV1rMSQcoiN iW2h3WoCGTVhHW3Nq237PuqHlLuiaaXAGJA3nzjurqkRFb3FEh/wynMPYBOv6QOnuP0V IfU+vDieLt/804dQa7yWhYlFBDFDTRYjLq9rBxL8/9joyaLO2iZyOw8r5jIxXPinsGsK PK1w== X-Gm-Message-State: AOAM533w8NMBFmg0GF+NFtFguu8hRNpbEwypq+jclAdILQdCaFYWfJ56 DAYW9ZJA9+1tGiPHc2QrC2rORaM/kdP865VuVaU= X-Google-Smtp-Source: ABdhPJz0SkQHyl9cOzOo1cSfQY2cy+KLk4vDm0OIfh9qZuy+wjsGfiQR1elZLg+shom2Gz1mFBcmeg== X-Received: by 2002:a17:906:24db:: with SMTP id f27mr17754938ejb.521.1629406723351; Thu, 19 Aug 2021 13:58:43 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id r2sm2370853edv.78.2021.08.19.13.58.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 13:58:43 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id f5so10920872wrm.13 for ; Thu, 19 Aug 2021 13:58:43 -0700 (PDT) X-Received: by 2002:a19:4f1a:: with SMTP id d26mr11559422lfb.377.1629406326706; Thu, 19 Aug 2021 13:52:06 -0700 (PDT) MIME-Version: 1.0 References: <20210816194840.42769-1-david@redhat.com> <20210816194840.42769-3-david@redhat.com> In-Reply-To: <20210816194840.42769-3-david@redhat.com> From: Linus Torvalds Date: Thu, 19 Aug 2021 13:51:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/7] kernel/fork: factor out replacing the current MM exe_file To: David Hildenbrand 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E2519801A89C X-Stat-Signature: hmdnxzmwzfhuwi1wuafjpea8fd3n3g96 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Y+pU8j9v; dmarc=none; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-HE-Tag: 1629406724-123914 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: So I like this series. However, logically, I think this part in replace_mm_exe_file() no longer makes sense: On Mon, Aug 16, 2021 at 12:50 PM David Hildenbrand wrote: > > + /* Forbid mm->exe_file change if old file still mapped. */ > + old_exe_file = get_mm_exe_file(mm); > + if (old_exe_file) { > + mmap_read_lock(mm); > + for (vma = mm->mmap; vma && !ret; vma = vma->vm_next) { > + if (!vma->vm_file) > + continue; > + if (path_equal(&vma->vm_file->f_path, > + &old_exe_file->f_path)) > + ret = -EBUSY; > + } > + mmap_read_unlock(mm); > + fput(old_exe_file); > + if (ret) > + return ret; > + } and should just be removed. 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. I just quoted it in the context of this patch, since the next patch doesn't actually show this code any more. In the *old* model - where the ETXTBUSY was about the mmap() of the file - the above tests make sense. 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. Hmm? Linus