(2) Consequently, commit c46a7c817e66 from 2014 does not tell the whole story. commit 21d9ee3eda77 ("mm: remove remaining references to NUMA hinting bits and helpers") from 2015 made the distinction again impossible. Setting FOLL_FORCE | FOLL_HONOR_NUMA_HINT would end up never making progress in GUP with an inaccessible (PROT_NONE) VMA.If we also teach follow_page_mask() on vma_is_accessible(), we should still be good, am I right? Basically fast-gup will stop working on protnone, and it always fallbacks to slow-gup. Then it seems we're good decoupling FORCE with NUMA hint. I assume that that's what you did below in the patch too, which looks right to me.
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.
[...]
+/* + * Indicates whether GUP can follow a PROT_NONE mapped page, or whether + * a (NUMA hinting) fault is required. + */ +static inline bool gup_can_follow_protnone(struct vm_area_struct *vma, + unsigned int flags) +{ + /* + * If callers don't want to honor NUMA hinting faults, no need to + * determine if we would actually have to trigger a NUMA hinting fault. + */ + if (!(flags & FOLL_HONOR_NUMA_FAULT)) + return true; + + /* We really need the VMA ... */ + if (!vma) + return false;I'm not sure whether the compiler will be smart enough to inline this for fast-gup on pmd/pte.
Why shouldn't it? It's placed in a head file and the vma == NULL is not obfuscated. :)
Anyhow, I'll take a look at the compiler output. Thanks! -- Cheers, David / dhildenb
