On Thu, 6 Jul 2023 21:32:10 -0700 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > With recent changes necessitating mmap_lock to be held for write while > expanding a stack, per-VMA locks should follow the same rules and be > write-locked to prevent page faults into the VMA being expanded. Add > the necessary locking. What are the possible runtime effects of this change? > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1977,6 +1977,8 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address) > return -ENOMEM; > } > > + /* Lock the VMA before expanding to prevent concurrent page faults */ > + vma_start_write(vma); > /* > * vma->vm_start/vm_end cannot change under us because the caller > * is required to hold the mmap_lock in read mode. We need the > @@ -2064,6 +2066,8 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address) > return -ENOMEM; > } > > + /* Lock the VMA before expanding to prevent concurrent page faults */ > + vma_start_write(vma); > /* > * vma->vm_start/vm_end cannot change under us because the caller > * is required to hold the mmap_lock in read mode. We need the > -- > 2.41.0.255.g8b1d071c50-goog
