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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>