Messages in this thread | | | Date | Mon, 31 Jul 2023 18:20:07 +0200 | Subject | Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout | From | David Hildenbrand <> |
| |
>> (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
| |