On Thu, Jun 6, 2019 at 5:49 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, 5 Jun 2019 17:10:19 +0800 Pingfan Liu <kernelfans@xxxxxxxxx> wrote:
>
> > As for FOLL_LONGTERM, it is checked in the slow path
> > __gup_longterm_unlocked(). But it is not checked in the fast path, which
> > means a possible leak of CMA page to longterm pinned requirement through
> > this crack.
> >
> > Place a check in the fast path.
>
> I'm not actually seeing a description (in either the existing code or
> this changelog or patch) an explanation of *why* we wish to exclude CMA
> pages from longterm pinning.
>
What about a short description like this:
FOLL_LONGTERM suggests a pin which is going to be given to hardware
and can't move. It would truncate CMA permanently and should be
excluded.
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -2196,6 +2196,26 @@ static int __gup_longterm_unlocked(unsigned long start, int nr_pages,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_CMA
> > +static inline int reject_cma_pages(int nr_pinned, struct page **pages)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < nr_pinned; i++)
> > + if (is_migrate_cma_page(pages[i])) {
> > + put_user_pages(pages + i, nr_pinned - i);
> > + return i;
> > + }
> > +
> > + return nr_pinned;
> > +}
>
> There's no point in inlining this.
OK, will drop it in V4.
>
> The code seems inefficient. If it encounters a single CMA page it can
> end up discarding a possibly significant number of non-CMA pages. I
The trick is the page is not be discarded, in fact, they are still be
referrenced by pte. We just leave the slow path to pick up the non-CMA
pages again.
> guess that doesn't matter much, as get_user_pages(FOLL_LONGTERM) is
> rare. But could we avoid this (and the second pass across pages[]) by
> checking for a CMA page within gup_pte_range()?
It will spread the same logic to hugetlb pte and normal pte. And no
improvement in performance due to slow path. So I think maybe it is
not worth.
>
> > +#else
> > +static inline int reject_cma_pages(int nr_pinned, struct page **pages)
> > +{
> > + return nr_pinned;
> > +}
> > +#endif
> > +
> > /**
> > * get_user_pages_fast() - pin user pages in memory
> > * @start: starting user address
> > @@ -2236,6 +2256,9 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
> > ret = nr;
> > }
> >
> > + if (unlikely(gup_flags & FOLL_LONGTERM) && nr)
> > + nr = reject_cma_pages(nr, pages);
> > +
>
> This would be a suitable place to add a comment explaining why we're
> doing this...
Would add one comment "FOLL_LONGTERM suggests a pin given to hardware
and rarely returned."
Thanks for your kind review.
Regards,
Pingfan
