Re: [RFP-V2 0/3] Make mmu_notifier_invalidate_range_start able to sleep.

[Andrea Arcangeli <aarcange@redhat.com>]

On Tue, Feb 02, 2010 at 10:39:30AM -0600, Robin Holt wrote:
> On Tue, Feb 02, 2010 at 05:01:46PM +0100, Andrea Arcangeli wrote:
> > On Tue, Feb 02, 2010 at 09:21:42AM -0600, Robin Holt wrote:
> > > unmap_mapping_range_vma would then unlock the i_mmap_lock, call
> > > _inv_range_start(atomic==0) which would clear all the remote page tables
> > > and TLBs.  It would then reaquire the i_mmap_lock and retry.
> > 
> > I guess you missed why we hold the i_mmap_lock there... it's not like
> > gratuitous locking complication there's an actual reason why it's
> > taken, and it's to avoid the vma to be freed from under you:
> 
> Oversight on my part.  Sorry.
> 
> Will this work?

No, it still corrupts memory as before. You need to re-run find_vma
under mmap_sem. Then it could work...

Also it's wrong to pin mm_users, you only need mm_count here, as you
only need to run find_vma, you don't need to prevent exit to free the
pages indefinitely while you're blocked.

> static int unmap_mapping_range_vma(struct vm_area_struct *vma,
> ...
> 	if (need_unlocked_invalidate) {
> 		mm = vma->vm_mm;
> 		atomic_inc(&mm->mm_users);
> 	}
> 	spin_unlock(details->i_mmap_lock);
> 	if (need_unlocked_invalidate) {
> 		/*
> 		 * zap_page_range failed to make any progress because the
> 		 * mmu_notifier_invalidate_range_start was called atomically
> 		 * while the callee needed to sleep.  In that event, we
> 		 * make the callout while the i_mmap_lock is released.
> 		 */
> 		mmu_notifier_invalidate_range_start(mm, start_addr, end_addr, 0);
> 		mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
> 		mmput(mm);
> 	}
> 	cond_resched();
> 	spin_lock(details->i_mmap_lock);
> 	return -EINTR;
> 
> Robin
> 

--
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>