From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
liubo <liubo254@huawei.com>, Peter Xu <peterx@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Hugh Dickins <hughd@google.com>, Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout
Date: Fri, 28 Jul 2023 09:18:45 -0700 [thread overview]
Message-ID: <CAHk-=wiig=N75AGP7UAG9scmghWAqsTB5NRO6RiWLOB5YWfcTQ@mail.gmail.com> (raw)
In-Reply-To: <20230727212845.135673-1-david@redhat.com>
On Thu, 27 Jul 2023 at 14:28, David Hildenbrand <david@redhat.com> 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
next prev parent reply other threads:[~2023-07-28 16:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 21:28 David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 2/4] mm/gup: Make follow_page() succeed again on PROT_NONE PTEs/PMDs David Hildenbrand
2023-07-28 2:30 ` John Hubbard
2023-07-28 9:08 ` David Hildenbrand
2023-07-28 10:12 ` David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 3/4] smaps: use vm_normal_page_pmd() instead of follow_trans_huge_pmd() David Hildenbrand
2023-07-27 21:28 ` [PATCH v1 4/4] mm/gup: document FOLL_FORCE behavior David Hildenbrand
2023-07-28 16:18 ` Linus Torvalds [this message]
2023-07-28 17:30 ` [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout David Hildenbrand
2023-07-28 17:54 ` David Hildenbrand
2023-07-28 19:40 ` David Hildenbrand
2023-07-28 19:50 ` Peter Xu
2023-07-28 20:00 ` David Hildenbrand
2023-08-02 10:24 ` Mel Gorman
2023-07-28 19:39 ` Peter Xu
2023-07-28 19:52 ` David Hildenbrand
2023-07-28 20:23 ` Linus Torvalds
2023-07-28 20:33 ` David Hildenbrand
2023-07-28 20:50 ` Linus Torvalds
2023-07-28 21:02 ` David Hildenbrand
2023-07-28 21:20 ` Peter Xu
2023-07-28 21:31 ` David Hildenbrand
2023-07-28 22:14 ` Jason Gunthorpe
2023-07-31 16:01 ` Peter Xu
2023-07-28 21:32 ` John Hubbard
2023-07-28 21:49 ` Peter Xu
2023-07-28 22:00 ` John Hubbard
2023-07-31 16:05 ` Peter Xu
[not found] ` <412bb30f-0417-802c-3fc4-a4e9d5891c5d@redhat.com>
2023-07-29 9:35 ` David Hildenbrand
2023-07-31 16:10 ` Peter Xu
2023-07-31 16:20 ` David Hildenbrand
2023-07-31 18:23 ` Linus Torvalds
2023-07-31 18:51 ` Peter Xu
2023-07-31 19:00 ` David Hildenbrand
2023-07-31 19:07 ` Linus Torvalds
2023-07-31 19:22 ` David Hildenbrand
2023-08-01 13:05 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wiig=N75AGP7UAG9scmghWAqsTB5NRO6RiWLOB5YWfcTQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liubo254@huawei.com \
--cc=peterx@redhat.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox