UPSTREAM: mm: lock newly mapped VMA which can be modified after it becomes visible
mmap_region adds a newly created VMA into VMA tree and might modify it afterwards before dropping the mmap_lock. This poses a problem for page faults handled under per-VMA locks because they don't take the mmap_lock and can stumble on this VMA while it's still being modified. Currently this does not pose a problem since post-addition modifications are done only for file-backed VMAs, which are not handled under per-VMA lock. However, once support for handling file-backed page faults with per-VMA locks is added, this will become a race. Fix this by write-locking the VMA before inserting it into the VMA tree. Other places where a new VMA is added into VMA tree do not modify it after the insertion, so do not need the same locking. Cc: stable@vger.kernel.org Signed-off-by: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 33313a747e81af9f31d0d45de78c9397fa3655eb) Change-Id: I3bb6a7bc8dd579e11f9c18cbc8e4a6e7279bbfb2 Signed-off-by: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This commit is contained in:
parent
05f7c7fe72
commit
e3601b25ae
1 changed files with 2 additions and 0 deletions
|
|
@ -2902,6 +2902,8 @@ cannot_expand:
|
|||
if (vma->vm_file)
|
||||
i_mmap_lock_write(vma->vm_file->f_mapping);
|
||||
|
||||
/* Lock the VMA since it is modified after insertion into VMA tree */
|
||||
vma_start_write(vma);
|
||||
mas_store_prealloc(&mas, vma);
|
||||
mm->map_count++;
|
||||
if (vma->vm_file) {
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue