Messages in this thread | | | From | David Hildenbrand <> | Subject | [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout | Date | Thu, 27 Jul 2023 23:28:41 +0200 |
| |
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.
(maybe it's just me who considers that confusing)
Patch #1 is the original fix proposal, which patch #3 cleans up. Patch #2 is another fix for the issue on the follow_page() level pointed out by Peter. Patch #4 documents the FOLL_FORCE situation.
Peter prefers a revert of that commit [1], I disagree and am still happy to see FOLL_NUMA gone that implicitly relied on FOLL_FORCE.
An alternative might be to use an internal FOLL_PROTNONE or FOLL_NO_PROTNONE flag in patch #3, not so sure about that.
Did a quick sanity test, will do more testing tomorrow.
[1] https://lkml.kernel.org/r/ZMK+jSDgOmJKySTr@x1n
Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: liubo <liubo254@huawei.com> Cc: Peter Xu <peterx@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Hugh Dickins <hughd@google.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: John Hubbard <jhubbard@nvidia.com>
David Hildenbrand (3): mm/gup: Make follow_page() succeed again on PROT_NONE PTEs/PMDs smaps: use vm_normal_page_pmd() instead of follow_trans_huge_pmd() mm/gup: document FOLL_FORCE behavior
liubo (1): smaps: Fix the abnormal memory statistics obtained through /proc/pid/smaps
fs/proc/task_mmu.c | 3 +-- include/linux/mm_types.h | 25 ++++++++++++++++++++++++- mm/gup.c | 10 +++++++++- 3 files changed, 34 insertions(+), 4 deletions(-)
-- 2.41.0
| |