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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B45F7C433FE for ; Wed, 16 Nov 2022 18:16:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234908AbiKPSQ5 (ORCPT ); Wed, 16 Nov 2022 13:16:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239079AbiKPSQz (ORCPT ); Wed, 16 Nov 2022 13:16:55 -0500 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64A2F623A1 for ; Wed, 16 Nov 2022 10:16:54 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z1so12201186qkl.9 for ; Wed, 16 Nov 2022 10:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PBgZn+u117R7gFQNpsnvlIYlwSeo0LUTLoxlFKr3wyI=; b=eH0YS14VezMu1YoYc8i9L/9V4Rda12NtBPhbyEQG9con1K8dLIyV9b4KNCmIq0wzpX WqxRC9GRz2SSVMeoKLZbZ25GRVxvk4TLZwapfzc9KJm3PzFnUZgrmijMI3uqPEOn38/b +5K39+JbiCr6klzOuT84Gyzf87KIYKFM/ltfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PBgZn+u117R7gFQNpsnvlIYlwSeo0LUTLoxlFKr3wyI=; b=1WtnoOqhEQ7whAwCKwr9/01rvT6pd9wwMFZMC1zC22a7m4EM7gOPibfpqOShcNZLXf dUgUHozXxIxSF5vUqSu++vXRURM6KR9o+VomwPKOEx48ZYFiUfd9KeDAu7oMECb+IVZE DQbQdemP3cAPz5d3XKrqaht0u7LEEI14IzQptfZYotz2+KaaDpzORipI3A9xAdHqUXzU x37I0LJEEpYhidVuwQU0s7F7Naf0W9UvBDbUqpFUgdm8Q9sLHrfWtbiBxmdxiQ4YdWQx 9ism6RYRDL2KSe0X5t2GBH/zWfmJyfXMlHQvn9NR9GhQcvP6XeC5SMphwJPU87Ls2ukH zD7w== X-Gm-Message-State: ANoB5pkLA1YGwJtjExl3OSV0NThVKmuy1fm7OYd8194syx+Kl5z/JL97 zRMuh6KVZiHkg7dekIjgYURPmQUoEJT4XA== X-Google-Smtp-Source: AA0mqf4ER6OfizqMRSTN00Aw9gcESQJcfC91oF+lsz/NKlnavHeBKp/gDej27xFsz9P0FjTbesASYA== X-Received: by 2002:a05:620a:270d:b0:6fb:982e:a66f with SMTP id b13-20020a05620a270d00b006fb982ea66fmr9588941qkp.344.1668622613164; Wed, 16 Nov 2022 10:16:53 -0800 (PST) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com. [209.85.160.172]) by smtp.gmail.com with ESMTPSA id l9-20020a05622a174900b003a611cb2a95sm560305qtk.9.2022.11.16.10.16.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 10:16:51 -0800 (PST) Received: by mail-qt1-f172.google.com with SMTP id jr19so11219166qtb.7 for ; Wed, 16 Nov 2022 10:16:51 -0800 (PST) X-Received: by 2002:a05:622a:1c15:b0:3a5:49fa:3983 with SMTP id bq21-20020a05622a1c1500b003a549fa3983mr21860304qtb.436.1668622610752; Wed, 16 Nov 2022 10:16:50 -0800 (PST) MIME-Version: 1.0 References: <20221116102659.70287-1-david@redhat.com> <20221116102659.70287-21-david@redhat.com> In-Reply-To: <20221116102659.70287-21-david@redhat.com> From: Linus Torvalds Date: Wed, 16 Nov 2022 10:16:34 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH mm-unstable v1 20/20] mm: rename FOLL_FORCE to FOLL_PTRACE To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, Andrew Morton , Jason Gunthorpe , John Hubbard , Peter Xu , Greg Kroah-Hartman , Andrea Arcangeli , Hugh Dickins , Nadav Amit , Vlastimil Babka , Matthew Wilcox , Mike Kravetz , Muchun Song , Shuah Khan , Lucas Stach , David Airlie , Oded Gabbay , Arnd Bergmann , Christoph Hellwig , Alex Williamson , Oleg Nesterov , Richard Henderson , Ivan Kokshaysky , Matt Turner , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Richard Weinberger , Anton Ivanov , Johannes Berg , Eric Biederman , Kees Cook , Alexander Viro , Peter Zijlstra , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Kentaro Takeda , Tetsuo Handa , Paul Moore , James Morris , "Serge E. Hallyn" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand wrote: > > Let's make it clearer that functionality provided by FOLL_FORCE is > really only for ptrace access. I'm not super-happy about this one. I do understand the "let's rename the bit so that no new user shows up". And it's true that the main traditional use is ptrace. But from the patch itself it becomes obvious that no, it's not *just* ptrace. At least not yet. It's used for get_arg_page(), which uses it to basically look up (and install) pages in the newly created VM. Now, I'm not entirely sure why it even uses FOLL_FORCE, - I think it might be historical, because the target should always be the new stack vma. Following the history of it is a big of a mess, because there's a number of renamings and re-organizations, but it seems to go back to 2007 and commit b6a2fea39318 ("mm: variable length argument support"). Before that commit, we kept our own array of "this is the set of pages that I will install in the new VM". That commit basically just inserts the pages directly into the VM instead, getting rid of the array size limitation. So at a minimum, I think that FOLL_FORCE would need to be removed before any renaming to FOLL_PTRACE, because that's not some kind of small random case. It *might* be as simple as just removing it, but maybe there's some reason for having it that I don't immediately see. There _are_ also small random cases too, like get_cmdline(). Maybe that counts as ptrace, but the execve() case most definitely does not. Linus