Re: [bug report] mm/mremap: complete refactor of move_vma()

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Wed, Jun 25, 2025 at 06:35:59PM +0300, Dan Carpenter wrote:
> On Wed, Jun 25, 2025 at 04:28:51PM +0100, Lorenzo Stoakes wrote:
> There is an earlier error path.
>
>   1750  static int copy_vma_and_data(struct vma_remap_struct *vrm,
>   1751                               struct vm_area_struct **new_vma_ptr)
>   1752  {
>   1753          unsigned long internal_offset = vrm->addr - vrm->vma->vm_start;
>   1754          unsigned long internal_pgoff = internal_offset >> PAGE_SHIFT;
>   1755          unsigned long new_pgoff = vrm->vma->vm_pgoff + internal_pgoff;
>   1756          unsigned long moved_len;
>   1757          struct vm_area_struct *vma = vrm->vma;
>   1758          struct vm_area_struct *new_vma;
>   1759          int err = 0;
>   1760          PAGETABLE_MOVE(pmc, NULL, NULL, vrm->addr, vrm->new_addr, vrm->old_len);
>   1761          bool relocate_anon = should_relocate_anon(vrm, &pmc, &err);
>   1762
>   1763          if (err)
>   1764                  return err;
>                         ^^^^^^^^^^^
> Here.

The bug report is against the wrong patch, the error was introduced by
'mm/mremap: add MREMAP_MUST_RELOCATE_ANON' (i.e. this check).

I'm looking at a massive refactor which removess this and checked against
'mm/mremap: complete refactor of move_vma()' which is why I missed this :)

Since I'm respinning anyway I'll just ask Andrew to drop the series for now
until I come back with the reworked version.

Thanks for the report!

>
>   1765
>   1766  again:
>   1767          new_vma = copy_vma(&vma, vrm->new_addr, vrm->new_len, new_pgoff,
>   1768                             &pmc.need_rmap_locks, &relocate_anon);
>   1769          if (!new_vma) {
>   1770                  vrm_uncharge(vrm);
>   1771                  *new_vma_ptr = NULL;
>   1772                  return -ENOMEM;
>   1773          }
>
> regards,
> dan carpenter
>
>