On Mon, 26 Jun 2023 at 08:50, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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
