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@xxxxxxxxxxxxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: liubo <liubo254@xxxxxxxxxx>
Cc: Peter Xu <peterx@xxxxxxxxxx>
Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Jason Gunthorpe <jgg@xxxxxxxx>
Cc: John Hubbard <jhubbard@xxxxxxxxxx>
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
