mm: fix __access_remote_vm() GUP failure case

Commit ca5e8632 ("mm/gup: remove vmas parameter from
get_user_pages_remote()") removed the vma argument from GUP handling,
and instead added a helper function (get_user_page_vma_remote()) that
looks it up separately using 'vma_lookup()'.  And then converted
existing users that needed a vma to use the helper instead.

However, the helper function intentionally acts exactly like the old
get_user_pages_remote() did, and only fills in 'vma' on successful page
lookup.  Fine so far.

However, __access_remote_vm() wants the vma even for the unsuccessful
case, and used to do a

	vma = vma_lookup(mm, addr);

explicitly to look it up when the get_user_page() failed.

However, that conversion commit incorrectly removed that vma lookup,
thinking that get_user_page_vma_remote() would have done it.  Not so.

So add the vma_lookup() back in.

Fixes: ca5e8632 ("mm/gup: remove vmas parameter from get_user_pages_remote()")
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/memory.c

@@ -5592,6 +5592,7 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
 			 * Check if this is a VM_IO | VM_PFNMAP VMA, which
 			 * we can access using slightly different code.
 			 */
+			vma = vma_lookup(mm, addr);
 			if (!vma)
 				break;
 			if (vma->vm_ops && vma->vm_ops->access)