Possible race with page_maybe_dma_pinned?

[Peter Xu <peterx@redhat.com>]

Hi, all,

It seems to be racy to call page_maybe_dma_pinned() without properly taking the
mm->write_protect_seq lock, which is taken read for fast gup.

Now we have 3 callers of page_maybe_dma_pinned():

        1. page_needs_cow_for_dma
        2. pte_is_pinned
        3. shrink_page_list

The 1st one is good as it takes the seqlock for write properly.  The 2nd & 3rd
are missing, we may need to add them.

The race could trigger when the fast-gup of FOLL_PIN happened right after a
call to page_maybe_dma_pinned() which returned false.  One example for page
reclaim of above case 3:

          fast-gup thread                      page reclaim thread
          ---------------                      -------------------
                                          page_maybe_dma_pinned --> false
                                          put the page into swap cache
      fast-gup with FOLL_PIN
                                          unmap page in pgtables
                                          ...

So commit feb889fb40fa ("mm: don't put pinned pages into the swap cache",
2021-01-17) could still have a small window that will stop working.

Same thing to the pte_is_pinned for clear_refs, which is case 2nd above.

If anyone agrees, and if anyone would like to fix this, please add:

Reported-by: Andrea Arcangeli <aarcange@redhat.com>

As this is originally spotted and reported by Andrea.

Thanks,

-- 
Peter Xu