Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230626085035.e66992e96b4c6d37dad54bd9@linux-foundation.org>
In-Reply-To: <20230626085035.e66992e96b4c6d37dad54bd9@linux-foundation.org>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 28 Jun 2023 12:19:42 -0700
Message-ID: <CAHk-=whppqqPdjVOx0mONDFx+JjewZPacionbWCUUFdrfOon-g@mail.gmail.com>
Subject: Re: [GIT PULL] MM updates for 6.5-rc1
To:     Andrew Morton <akpm@linux-foundation.org>,
        Lorenzo Stoakes <lstoakes@gmail.com>
Cc:     linux-mm@kvack.org, mm-commits@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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