On 03/11/2023 08:53, Amit Daniel Kachhap wrote:
On 10/27/23 19:36, Kevin Brodsky wrote:
On 25/10/2023 07:36, Amit Daniel Kachhap wrote:
[...]
@@ -3362,6 +3366,8 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, new_vma->vm_start = addr; new_vma->vm_end = addr + len; new_vma->vm_pgoff = pgoff; + if (vma->vm_flags & VM_PCUABI_RESERVE) + reserv_vma_insert_entry(new_vma, addr, len, 0); if (vma_dup_policy(vma, new_vma)) goto out_free_vma; if (anon_vma_clone(new_vma, vma))
I don't think these changes are particularly related to mremap(), mapping can be split or merged for other reasons. It would make sense to have a separate patch for everything concerning mapping / reservation interactions that isn't related to a specific syscall.
mremap is the only user of copy_vma(). Anyways I can try adding vma operations (copy_vma, merge_vma) in a single patch.
Right sorry, I didn't mean this hunk, as it is indeed only relevant to mremap(), but rather the changes to vma_merge(), which impact most m* syscalls.
Kevin