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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA2E0C0015E for ; Fri, 28 Jul 2023 16:19:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80B028D0003; Fri, 28 Jul 2023 12:19:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BB9C8D0001; Fri, 28 Jul 2023 12:19:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A9758D0003; Fri, 28 Jul 2023 12:19:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5C46F8D0001 for ; Fri, 28 Jul 2023 12:19:07 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 09D11120701 for ; Fri, 28 Jul 2023 16:19:07 +0000 (UTC) X-FDA: 81061529934.30.7FC5B43 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf02.hostedemail.com (Postfix) with ESMTP id BC2CD80020 for ; Fri, 28 Jul 2023 16:19:04 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bynKf6n+; dmarc=none; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690561144; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oiqXtLXb56gWHpFHlkrGXB0htpi3zn1ShhYELBek5ko=; b=ZXPVz7mqADYXZTbuoJ8Ole2NlbU90p4ftFAV1XwgFXuVLFpY4HChypjQLO0OVAnR2NjRJ8 ttuztk63gppEjjJ+TR4ZQkRt2yXZ8wBISL+ohXjHTfuzATizTjDMOHWSJ9nBMHy5VoVs89 HlzCX6p73F1jHQo1/5Wg8wI7zm09d4M= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bynKf6n+; dmarc=none; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690561144; a=rsa-sha256; cv=none; b=G80mFO2YmA9ozFAtZBcYdyxz3Zth9sF8sDe5XSQKu3SRKiOcAy3jueJ9dUhDX/EgZ678OM DO6KlD70NrezaXR9ZhapkmdtwHyJM4X3q4FEkKPWjdUovGqP8MlojdmDAg0OT5ix6M7luJ lWubpN3T8PVtvyQcgw8iGnzjSdTgMnE= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-99bed101b70so129084566b.3 for ; Fri, 28 Jul 2023 09:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1690561143; x=1691165943; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oiqXtLXb56gWHpFHlkrGXB0htpi3zn1ShhYELBek5ko=; b=bynKf6n+TpRfz0DyR2rYNbqu0v4M0dTgmVz8xWQq8X+28lhY2cl5XnPRKgqX9HAqiE H79vFTkAB/9Itwu2leZ1xBpWwBB4F2uReu+dWnEz72qQ+dgV9BK2g3sOlh+7HQG5ShkZ 9P+UQsfvk3Zbb2D6K+z9GjqGwuGQGpMLf/2Vk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690561143; x=1691165943; 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=oiqXtLXb56gWHpFHlkrGXB0htpi3zn1ShhYELBek5ko=; b=YmFz0ryJRY8tVIW86x/FUY1iL+XKC5jh9x48WsE4JAzU0uZ2kXe/cp03x7cAEgCCPU SzBCJt9gbuudlFk2JVpuwtM45+QBxerxh7+Xb9gwsE2Wh9f/Rdf5sSPNWUK0HiJGv2bP +7pidHs3CWQSRATGLtkw7rtOXuuVCKCYJ3joiHadxyjwpsIGu7mOQCi9tgNJWTwDJCcb H+0ShRngqTs/ZmQk0fnaHQAMLllKLx8LSqrj1x+LC1UwKvg7pi10KguHfL9Fe8vXeMnh zjNDbbe+GjyVHfOtkrH/5injhUU9lYnL+Ax6K0DJjM3o4xmMP6qSflVQK8hXk6f5lMby tYYQ== X-Gm-Message-State: ABy/qLZHqN9E70tRX9ijGxagU8334FrwnoGY3ebxRzgoXmGhsnRtLMrB ykeA83i1g4FhEk83IRHp4r8zWTYynhj36CFXFzwVFZtN X-Google-Smtp-Source: APBJJlGS1FYZa09Ynq7gxckWu5ZmwMAjkJfhyTdB5VQz2qknnMa7t4KxnF4HynAMIs0D3anMz/MREg== X-Received: by 2002:a17:906:209:b0:99b:d168:41e5 with SMTP id 9-20020a170906020900b0099bd16841e5mr2918263ejd.54.1690561142903; Fri, 28 Jul 2023 09:19:02 -0700 (PDT) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id f23-20020a170906495700b0098748422178sm2206069ejt.56.2023.07.28.09.19.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 09:19:02 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5221cf2bb8cso3075337a12.1 for ; Fri, 28 Jul 2023 09:19:02 -0700 (PDT) X-Received: by 2002:a05:6402:1141:b0:51e:5322:a642 with SMTP id g1-20020a056402114100b0051e5322a642mr2296690edw.27.1690561141923; Fri, 28 Jul 2023 09:19:01 -0700 (PDT) MIME-Version: 1.0 References: <20230727212845.135673-1-david@redhat.com> In-Reply-To: <20230727212845.135673-1-david@redhat.com> From: Linus Torvalds Date: Fri, 28 Jul 2023 09:18:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Andrew Morton , liubo , Peter Xu , Matthew Wilcox , Hugh Dickins , Jason Gunthorpe , John Hubbard Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BC2CD80020 X-Stat-Signature: hmtcqiud843wqdj1cie98d5xk6zfd45n X-HE-Tag: 1690561144-230363 X-HE-Meta: U2FsdGVkX18jv/ba/aTJGEZZYgZIR7h7q9O/1Q/iQGOP/7oN/yCodedI3UcVNCLdv5CXGvi91pmj8t9LvK0P8T3Whp/mtrndM+JHyVQ0q4I/B+cnPJGTqED6cXbhojLal9hDAfaXe03GmDBrxmQaTge1NsXFVZTiJH1FGcxjKhvF5P77gWtLscNiLiFF2BkynPW6Zx+8NYFffkG/XK4Pr3BQWtiT4/YtKuUKxLc1wTszNNEfAgF0HR7Atv4x3MczCdcQm2u1ow4unnsPRlvFNXtsgkn+IfZb+K3D5Fc028z8ld/hhBH5zWCpPCS1ORBf/MFbiHI+qKs1qjGysauw4aUvVAzOu+Q3R3/7/y6IL+TXRas18bzfQykSFdnr3VXZPdXLpgcYa13fI26fwo/bX77Qng+iuya1g7GUjMImv11oLgJStetuVhH8Pj5e1Y+e/PwoxOw8/EcVB4K110uyEqH2xFBSmXY/WNGsEiOnv6F2FeSjIJ0jx/r7XGpLoDGkNBNOawlvzKOyZnY0/4phpeHKO7sEkhOYqi2DbPTXX5SXehFzuavYo+tcCDlq/WtSLbAyJ+a7nSLHlnNWj2VqTBRCNGCGlPG0/6P6mbunxhJCToNmsa/OQoOHe55Zw3sV2pivd3VahmzlFtFfAc0PDBO75RFTcamoUiRY8kF1RDtPxCFdE1ThmoEYddnyF+bFoMDWDzkrp1PvaKOZnzVH7bWRboeoG206AiOXLyYlRzERMU60163Dl9PRfL5DX03eeFdAgyqON44aQhx7yyfObLhuVGJDbnfqL0FWBhrZfPm02FRZ9CEgqIapLr+VSYLUiHdCfnVVyV9jYraW5MuGerI/9+5g5w3T5cOToChDOeAHmdf6UvSqIO7iyrek6GoXyV0ngfd81tVMz9dFHl1I7sQV6vjIlzl4ddLgpowtKiqucBiX2foxnRwhtz1R9cm3YxdnZdovsARsXwvoj2A +UkQ/nBY EVmvNnSMBVDj4EUw54diyClXnT3K6l8JIFfqV07sJa7jUUxQnQ555Q8kd9hlCnYirHKAAXcXAvTSpH1SHRB2LEC9QYjPHAa9Fvfpp4dIexThPfSm7U1HJNS/7B15JCiFw9fAKFThr1DtFXng7zWhoHEJMCBXKy0OuRqYfmjqaRUfkSx+4PgjmyWONj0zQLIeslDBpU3J43mHxYshZUZ4RXvxdzEjclwqPLZuqy24kTpe3yf2CTja1EWQT828t5IrrLZw1OkaQiU033RfZhO50i35196Iyrq7yqjUT9B8q54RPTxWmYk5lbRUauY4oTcwwqRNT8vj6PYV2mlCK0LPJoPvLJXvJvEStlVzdRHtgYA3fAoJNGU+7hggZgYjFZhfLYg3Q5voYJk4ru1cya/Mnlf0cAEoIn2ZrIHzr+rdaIHAfFZrwwn6cSiMkpl3fUQbptXgyYlLzTIXvPSzseX2VYQnxxgrhN7Y+vX3lpzPJ2m0UeEWvHK1YlT/mJU8IWEEfgSfgVDi+wnQohqMK0bWWUfU7ZeKRo8RydJWgn80KGJQKelaUYE2UK4gICmkxV0DNftda 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 Thu, 27 Jul 2023 at 14:28, David Hildenbrand wrote: > > This is my proposal on how to handle the fallout of 474098edac26 > ("mm/gup: replace FOLL_NUMA by gup_can_follow_protnone()") where I > accidentially missed that follow_page() and smaps implicitly kept the > FOLL_NUMA flag clear by *not* setting it if FOLL_FORCE is absent, to > not trigger faults on PROT_NONE-mapped PTEs. Ugh. I hate how it uses FOLL_FORCE that is inherently scary. Why do we have that "gup_can_follow_protnone()" logic AT ALL? Couldn't we just get rid of that disgusting thing, and just say that GUP (and follow_page()) always just ignores NUMA hinting, and always just follows protnone? We literally used to have this: if (!(gup_flags & FOLL_FORCE)) gup_flags |= FOLL_NUMA; ie we *always* set FOLL_NUMA for any sane situation. FOLL_FORCE should be the rare crazy case. The original reason for not setting FOLL_NUMA all the time is documented in commit 0b9d705297b2 ("mm: numa: Support NUMA hinting page faults from gup/gup_fast") from way back in 2012: * If FOLL_FORCE and FOLL_NUMA are both set, handle_mm_fault * would be called on PROT_NONE ranges. We must never invoke * handle_mm_fault on PROT_NONE ranges or the NUMA hinting * page faults would unprotect the PROT_NONE ranges if * _PAGE_NUMA and _PAGE_PROTNONE are sharing the same pte/pmd * bitflag. So to avoid that, don't set FOLL_NUMA if * FOLL_FORCE is set. but I don't think the original reason for this is *true* any more. Because then two years later in 2014, in commit c46a7c817e66 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels") Mel made the code able to distinguish between PROT_NONE and NUMA pages, and he changed the comment above too. But I get the very very strong feeling that instead of changing the comment, he should have actually removed the comment and the code. So I get the strong feeling that all these FOLL_NUMA games should just go away. You removed the FOLL_NUMA bit, but you replaced it with using FOLL_FORCE. So rather than make this all even more opaque and make it even harder to figure out why we have that code in the first place, I think it should all just be removed. The original reason for FOLL_NUMA simply does not exist any more. We know exactly when a page is marked for NUMA faulting, and we should simply *ignore* it for GUP and follow_page(). I think we should treat a NUMA-faulting page as just being present (and not NUMA-fault it). Am I missing something? Linus