On Fri, Jul 7, 2023 at 7:27 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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? During the stack expansion concurrent page faults would have to wait and visa versa (stack expansion would have to wait if there are ongoing page faults). I think it's the same runtime effects as the recent similar change requiring mmap_lock to be write lock before stack expansion. > > > --- 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 > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
