• Hugh Dickins's avatar
    [PATCH] vmtrunc: vm_truncate_count race caution · 0b5d6831
    Hugh Dickins authored
    Fix some unlikely races in respect of vm_truncate_count.
    
    Firstly, it's supposed to be guarded by i_mmap_lock, but some places copy a
    vma structure by *new_vma = *old_vma: if the compiler implements that with a
    bytewise copy, new_vma->vm_truncate_count could be munged, and new_vma later
    appear up-to-date when it's not; so set it properly once under lock.
    
    vma_link set vm_truncate_count to mapping->truncate_count when adding an empty
    vma: if new vmas are being added profusely while vmtruncate is in progess,
    this lets them be skipped without scanning.
    
    vma_adjust has vm_truncate_count problem much like it had with anon_vma under
    mprotect merge: when merging be careful not to leave vma marked as up-to-date
    when it might not be, lest unmap_mapping_range in progress - set
    vm_truncate_count 0 when in doubt.  Similarly when mremap moving ptes from one
    vma to another.
    
    Cut a little code from __anon_vma_merge: now vma_adjust sets "importer" in the
    remove_next case (to get its vm_truncate_count right), its anon_vma is already
    linked by the time __anon_vma_merge is called.
    Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    0b5d6831
rmap.c 22.6 KB