On Thu, Feb 20, 2020 at 10:36:38AM -0800, Brian Geffon 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. Fair enough. It seems to be very old existing behavior but man page never mention about it. :( > > 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? Agreed. That makes code more simple/clean. Thanks!
