Re: [PATCH 09/10] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Aug 12, 2016 at 03:21:41PM +0200, Oleg Nesterov wrote:
> On 08/12, Michal Hocko wrote:
> >
> > > Let's CC Paul. Just to describe the situation. We have the following
> > > situation:
> > >
> > > #define __get_user_mm(mm, x, ptr)				\
> > > ({								\
> > > 	int ___gu_err = __get_user(x, ptr);			\
> > > 	if (!___gu_err && test_bit(MMF_UNSTABLE, &mm->flags))	\
> > > 		___gu_err = -EFAULT;				\
> > > 	___gu_err;						\
> > > })
> > >
> > > and the oom reaper doing:
> > >
> > > 	set_bit(MMF_UNSTABLE, &mm->flags);
> > >
> > > 	for (vma = mm->mmap ; vma; vma = vma->vm_next) {
> > > 		unmap_page_range
> > >
> > > I assume that write memory barrier between set_bit and unmap_page_range
> > > is not really needed because unmapping should already imply the memory
> > > barrier.
> 
> Well, I leave this to Paul, but...
> 
> I think it is not needed because we can rely on pte locking. We do
> not care if anything is re-ordered UNLESS __get_user() above actually
> triggers a fault and re-populates the page which was already unmapped
> by __oom_reap_task(), and in the latter case __get_user_mm() can't
> miss MMF_UNSTABLE simply because __get_user() and unmap_page_range()
> need to lock/unlock the same ptlock_ptr().
> 
> So we only need the compiler barrier to ensure that __get_user_mm()
> won't read MMF_UNSTABLE before __get_user(). But since __get_user()
> is function, it is not needed too.
> 
> There is a more interesting case when another 3rd thread can trigger
> a fault and populate this page before __get_user_mm() calls _get_user().
> But even in this case I think we are fine.

Hmmm...  What source tree are you guys looking at?  I am seeing some
of the above being macros rather than functions and others not being
present at all...

							Thanx, Paul

> Whats really interesting is that I still fail to understand do we really
> need this hack, iiuc you are not sure too, and Michael didn't bother to
> explain why a bogus zero from anon memory is worse than other problems
> caused by SIGKKILL from oom-kill.c.
> 
> Oleg.
> 

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