Re: [PATCH 1/1] mm: vma_merge: fix vm_page_prot SMP race condition against rmap_walk

[Andrea Arcangeli <aarcange@redhat.com>]

On Sat, Sep 17, 2016 at 06:05:15PM +0200, Andrea Arcangeli wrote:
> +	if (remove_next == 1) {
> +		/*
> +		 * vm_page_prot and vm_flags can be read by the
> +		 * rmap_walk, for example in remove_migration_ptes(),
> +		 * so before releasing the rmap locks the permissions
> +		 * of the expanded vmas must be already the correct
> +		 * one for the whole merged range.
> +		 *
> +		 * mprotect case 8 (which sets remove_next == 1) needs
> +		 * special handling to provide the above guarantee, as
> +		 * it is the only case where the "vma" that is being
> +		 * expanded is the one with the wrong permissions for
> +		 * the whole merged region. So copy the right
> +		 * permissions from the next one that is getting
> +		 * removed before releasing the rmap locks.
> +		 */
> +		vma->vm_page_prot = next->vm_page_prot;
> +		vma->vm_flags = next->vm_flags;
> +	}
>  	if (start != vma->vm_start) {

One more thought, doesn't remove_next get set to 1 also in case 7?

I assumed this could be fixed within vma_adjust but case 7 is
indistinguishable from case 8 from within vma_adjust. So the fix has
to move up one level in vma_merge where it's possible to differentiate
case 7 and case 8.

The fact no available testcase is exercising the race with any other
cases of vma_merge except case 8, makes the testing prone for false
negatives (accidentally upstream also initially passed as a false
negative thanks to the pmd_modify in do_numa_page that hidden the most
visible side effect of the bug even in case 8). All I can easily
verify with the testcase is that case 8 is fixed by monitoring any
erroneous do_numa_page execution on non-NUMA guests, and sure thing
case 8 was fixed.

I'll also reconsider how much more complex it is to remove the "area"
vma in case 8, instead of the "next", so that case 8 changes from
PPPPNNNNXXXX->PPPPNNNNNNNN to PPPPNNNNXXXX->PPPPXXXXXXXX, in turn
removing the oddness factor from case 8.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>