Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout

[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