Re: [GIT PULL] MM updates for 6.5-rc1

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 26 Jun 2023 at 08:50, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Linus, please merge the MM updates for the 6.5-rc cycle.

Hmm. I have merged this, as pr-tracker-bot already noticed, but I
found a bug after merging it.

mm/memory.c: __access_remote_vm() is entirely broken for the
HAVE_IOREMAP_PROT case (ie all normal architectures), because it does
(skipping the non-HAVE_IOREMAP_PROT case):

        struct vm_area_struct *vma = NULL;
        struct page *page = get_user_page_vma_remote(mm, addr,
                                                     gup_flags, &vma);

        if (IS_ERR_OR_NULL(page)) {
                [ ... ]
                if (!vma)
                        break;
                if (vma->vm_ops && vma->vm_ops->access)
                        res = vma->vm_ops->access(vma, addr, buf, ...

but get_user_page_vma_remote() doesn't even set vma if it fails!

So that "if (!vma)" case will always trigger, and the whole ->access()
thing is never done.

So that __access_remote_vm() conversion in commit ca5e863233e8
("mm/gup: remove vmas parameter from get_user_pages_remote()") is
entirely broken.

Now, I don't disagree with removing the vmas parameter. I just
disagree with the get_user_page_vma_remote() helper use here.

I think the minimal fix is to just put the vma_lookup() back in the error case:

    --- a/mm/memory.c
    +++ b/mm/memory.c
    @@ -5592,6 +5592,7 @@ int __access_remote_vm(struct mm_struct *mm,
                 * 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)

and I'll commit that fix for now. Anybody who disagrees, please holler.

                 Linus