Sorry I should clarify that this is the behavior with MREMAP_FIXED is used, and to expand on that, it would potentially even have unmapped the region at the destination address and then fail in vma_to_resize too, so I hope that explains why that check landed there. But should these situations be considered a bug? Brian On Thu, Feb 20, 2020 at 10:36 AM Brian Geffon <bgeffon@xxxxxxxxxx> wrote: > > Hi Minchan, > > > And here we got error if the addr is in non-anonymous-private vma so the > > syscall will fail but old vma is gone? I guess it's not your intention? > > This is exactly what happens today in several situations, because > vma_to_resize is called unconditionally. For example if the old vma > has VM_HUGETLB and old_len < new_len it would have unmapped a portion > and then in vma_to_resize returned -EINVAL, similarly when old_len = 0 > with a non-sharable mapping it will have called do_munmap only to fail > in vma_to_resize, if the vma has VM_DONTEXPAND set and you shrink the > size with old_len < new_len it would return -EFAULT after having done > the unmap on the decreased portion. So I followed the pattern to keep > the change simple and maintain consistency with existing behavior. > > But with that being said, Kirill made the point that resizing a VMA > while also using MREMAP_DONTUNMAP doesn't have any clear use case and > I agree with that, I'm unable to think of a situation where you'd want > to resize a VMA and use MREMAP_DONTUNMAP. So I'm tempted to mail a new > version which returns -EINVAL if old_len != new_len that would resolve > this concern here as nothing would be unmapped ever at the old > position add it would clean up the change to very few lines of code. > > What do you think? > > Thank you for taking the time to review. > > Brian
