[PATCH] fix split_vma vs. invalidate_mmap_range_list race
From: "V. Rajesh" <vrajesh@eecs.umich.edu> If a vma is already present in an i_mmap list of a mapping, then it is racy to update the vm_start, vm_end, and vm_pgoff members of the vma without holding the mapping's i_shared_sem. This is because the updates can race with invalidate_mmap_range_list. I audited all the places that assign vm_start, vm_end, and vm_pgoff. AFAIK, the following is the list of questionable places: 1) This patch fixes the racy split_vma. Kernel 2.4 does the right thing, but the following changesets introduced a race. http://linux.bkbits.net:8080/linux-2.5/patch@1.536.34.4 http://linux.bkbits.net:8080/linux-2.5/patch@1.536.34.5 You can use the patch and programs in the following URL to trigger the race. http://www-personal.engin.umich.edu/~vrajesh/linux/truncate-race/ 2) This patch also locks a small racy window in vma_merge. 3) In few cases vma_merge and do_mremap expand a vma by adding extra length to vm_end without holding i_shared_sem. I think that's fine. 4) In arch/sparc64, vm_end is updated without holding i_shared_sem. Check make_hugetlb_page_present. I hope that is fine, but I am not sure.
Showing
Please register or sign in to comment