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 919CDC001E0 for ; Mon, 31 Jul 2023 18:24:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13890280096; Mon, 31 Jul 2023 14:24:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E94228007A; Mon, 31 Jul 2023 14:24:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF2FB280096; Mon, 31 Jul 2023 14:24:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DFE6E28007A for ; Mon, 31 Jul 2023 14:24:21 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A57411202A7 for ; Mon, 31 Jul 2023 18:24:21 +0000 (UTC) X-FDA: 81072731922.26.CC7ADE7 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf21.hostedemail.com (Postfix) with ESMTP id 9757F1C0016 for ; Mon, 31 Jul 2023 18:24:19 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CtRurR7T; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690827859; 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=1JsJGaMslWBF9ml2379UCHrdiT1Bj5wN4ELxCIbCizg=; b=iOzxWy0jbhq2dX1gusaHa7458IYfMPuxxd8nVNy3F5ufXP6MVFVxkSJF/k8UoN/hZcOtlq bTd51CaRmAuzWTf1kazIJrcm/POiFcwJq2Ky6LZs45NepLironFFokkQGaqogv1KbjTbMZ vlzUhVbjG2j8fJ1iftdGucIDr8Bikng= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690827859; a=rsa-sha256; cv=none; b=0VkFykZ1KtNvm0zc+CmK7Y9VBwMU6LnZf1ryzqp3WON/AZeXWKrxr3ryhmRdxFg2uqAxIq X3fFHJvBv5avRqz+6aOoCg6y3iI4Xmbg6kVzQDjvtZO8AkOVGcn5WF7Tzop9HcQB4cFqhA wyaEDHMh8w/u9TCK4fELvx79EBm3puk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CtRurR7T; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4fe28f92d8eso3221360e87.1 for ; Mon, 31 Jul 2023 11:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1690827857; x=1691432657; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1JsJGaMslWBF9ml2379UCHrdiT1Bj5wN4ELxCIbCizg=; b=CtRurR7TocHfwYJED+G5FJni7/g3phT4SLTFdA3TZ23s5uriP01O/X5nquVcDm3ccP IwG96ndm/zHE233TIveqlV9fL/k3riH3i6vQuif/IIBJZiV+amRWGNzT11kEl0j4f7UX 4qcBotaaEm8KSelrT9L5ebHAjRNuDWzwNAGRU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690827857; x=1691432657; 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=1JsJGaMslWBF9ml2379UCHrdiT1Bj5wN4ELxCIbCizg=; b=LTzaNtcwSyxuQCdfDLyxhsrjEgMekKWqnzDM+OMAG1FbI1FrNSub8qv7SyBZu3lntF O14ekAVQ6jVkATjWR7t5/eMZeF7hTZ1uKVZFpJN3x4tt01PtxpK/XZNIN8eICNETjEMl x694dB92hia4B0n7SGvT1NyuHTHUjfXKJRZGYkF7ogRRz4/7g1cXXHikZHcygsuNA9fZ sEW+0nrqHjMRKn7gmS2y5U28bToOW1+VMuw3RQecodVPMHhEhP5hkE2xB/B4vPezZfa6 U+jVe4JD+1pPlKbkoHX/txdk6gIQRqWklZBZZ5x0pZqUjtQKqJCCswSqJzRuvTmc8R3j iISA== X-Gm-Message-State: ABy/qLZMRwNQIVmaqFU7KkXuus3+/Z8AvPaogiM1Gdk/1Z6bot3iEXyX eXOrh6JeJtLqZ3/M8VSXcpqNflNb00oKBEMoxQjT2oT/ X-Google-Smtp-Source: APBJJlHxnO+U/z2gHpSHUGbSShFzitcuHcQtuz33M+/ZDhyIhvJP8EIE/mwRSTfve3XTBvtLyyq2wg== X-Received: by 2002:a19:6711:0:b0:4fd:d517:fbcd with SMTP id b17-20020a196711000000b004fdd517fbcdmr516830lfc.6.1690827857648; Mon, 31 Jul 2023 11:24:17 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id v21-20020ac25615000000b004fcddf3671dsm77291lfd.177.2023.07.31.11.24.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jul 2023 11:24:16 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-4fe389d6f19so1823834e87.3 for ; Mon, 31 Jul 2023 11:24:16 -0700 (PDT) X-Received: by 2002:a05:6512:20c1:b0:4fd:faa3:2352 with SMTP id u1-20020a05651220c100b004fdfaa32352mr423948lfr.14.1690827855949; Mon, 31 Jul 2023 11:24:15 -0700 (PDT) MIME-Version: 1.0 References: <20230727212845.135673-1-david@redhat.com> <412bb30f-0417-802c-3fc4-a4e9d5891c5d@redhat.com> <66e26ad5-982e-fe2a-e4cd-de0e552da0ca@redhat.com> In-Reply-To: From: Linus Torvalds Date: Mon, 31 Jul 2023 11:23:59 -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: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Andrew Morton , liubo , Matthew Wilcox , Hugh Dickins , Jason Gunthorpe , John Hubbard , Mel Gorman Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9757F1C0016 X-Rspam-User: X-Stat-Signature: hxtbw4a1y7mrr5cx9e3kxfjqkygno3xx X-Rspamd-Server: rspam03 X-HE-Tag: 1690827859-199208 X-HE-Meta: U2FsdGVkX1+u3rnc+3aBmfo3H5sNyEKBQubHt8jDYZoW41NFptSf5Asn1u5u2Frsm/BGmIqnbjp4n4iefFaMR4c5NUNVrJqeMAKMl1KQJjdK+kdUxz7QNQfzX8HUsXGlgxy95yq6xX3qra/FNFoz8wqtxdDq8c+GJS0ixlUAOWer8kC4P1JxF3rFoctKQ3gYp/paF2oP9bOhTpWWr42wEIj/DuBgnTWUUtaj+AxLZKTRuvgTUNn2hzXfp+nfIRJEkcl+WQ6ic+WEuXjzly/x9LW59ealokVA3N216rwRH9tB9MUkbwh2rLJyGMHXVaKlDUs1uCPlNCm2AgEjqANorjOjwubJ/ItHvHPbnHSgbvtJONqo7NvSpxJKN93mA/1zzESS2/oUS6KQtlxbkvF9iPZglYDkJbcuhkb8TpCqEgw6YUz98jnAAPTZltH4gDeKn3yQlNxtCamrtYrWy6czMpPN9epC0SsHWLVtNoS/e5D6k8yORz5JLvaesTMbiE9sPJcM9zZ7in/hebRFGia1oPd7DEq4TW2b/ppwNhszzqSH5oPfBvdU5Tk8Y9JzvOMeFrGgyfeooDAudDkji+Fyklkub6vlCocd+YjMhPLLf7p8yL+Fk05IV1RsJpvvh1toFhDKQqseT/lYa0ymt110DS8X92dNwrOo9n3AVDuGKn2/UmnCAKO+NQcInc5WZt+IkBrlpEI7ZYNTrSytvGEbz31QvwJMGwR1qVjU9Z4pjs+fs9gWarXpCiMGb3jIzrRs/q1MRBgr15JaQ1YP8LNkM2oRxQlu8kWTSb/Io2mJb/F+K6e5FQ2gp8QvRJo+fks6ij0MnG7iXk3dAQlDQ1kUW8Gv8LX0kwxTeu1+WJiE/DXqdvvL0JGU6YPy01SoEQG5WpwNrBUDLiXJuOXm/IKI6QNNvtqFEmbj8NJhdhhCpT6jdZNyBcODeeNvuRtA/Bbebjbz0lUE8ULmkCjixAu 9YVDggGL QewcRFyyt9QXDLTy7aCzkK6bixWINqjB92TS1KHzT7jv9hrJdesJvlSDfiKjuSW4r6TYYVUh6pwVpWNvUZWEKJt2H6mpj8mZVuamfMqlAJTB3YwJg0vbbt6CSwkNoxwzdDJlBZJs0E/wQfGWHMmtZKnFGa0suklOmpi8douax1CWi0r1g3iKkoap+ncqYBMWlmI42i2YpXW/8Di56cz5p0HWdrNDc/CQDfNQHs/H9Ly3I9WKb4dszJNDL3FhtLZBppFbDEo72SzjkyX+StyCkKFtBgr3CCuJLiQk3abGQg505oZQDtCGsTuuNBj7mWr87mjU9Sm4wcgjhkfqfpdfU0zi5P/qHXjMy5S1tLKmueD3Ao7GMR74Cw7hLmlBIA2IzHk54bTt66VHmeFr8aIp/zWyRvgvgYGUxXhtHOSY84S5uSx7kgd7YCqNLqw6R6jppK1nQ+1ZGV/oyoUBVyjqayfr9Wi4WrzpsZzpyOHw+3Y3OgdjuHk5nbnQR5oxHgV8DHMJ3LxymH/6ydHmAnkSrkOKIcXzFhMOBzq+1Cph3CH674BzG2eOCCavMdVE0i8isNtpk 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 Mon, 31 Jul 2023 at 09:20, David Hildenbrand wrote: > > I modified it slightly: FOLL_HONOR_NUMA_FAULT is now set in > is_valid_gup_args(), such that it will always be set for any GUP users, > including GUP-fast. But do we actually want that? It is actively crazy to honor NUMA faulting at least for get_user_pages_remote(). So right now, GUP-fast requires us to honor NUMA faults, because GUP-fast doesn't have a vma (which in turn is because GUP-fast doesn't take any locks). So GUP-fast can only look at the page table data, and as such *has* to fail if the page table is inaccessible. But GUP in general? Why would it want to honor numa faulting? Particularly by default, and _particularly_ for things like FOLL_REMOTE. In fact, I feel like this is what the real rule should be: we simply define that get_user_pages_fast() is about looking up the page in the page tables. So if you want something that acts like a page table lookup, you use that "fast" thing. It's literally how it is designed. The whole - and pretty much only - point of it is that it can be used with no locking at all, because it basically acts like the hardware lookup does. So then if KVM wants to look up a page in the page table, that is what kvm should use, and it automatically gets the "honor numa faults" behavior, not because it sets a magic flag, but simply because that is how GUP-fast *works*. But if you use the "normal" get/pin_user_pages() function, which looks up the vma, at that point you are following things at a "software level", and it wouldn't do NUMA faulting, it would just get the page. (Ok, we have the whole "FAST_ONLY vs fall back" case, so "fast" can look up the vma too, but read the above argument as "fast *can* be done without vma, so fast must honor page table bits as per hardware"). Linus