On Fri 12-08-16 08:57:34, Paul E. McKenney wrote:
> 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...
The code is not upstream yet. You can find the current version of the
patchset here:
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git#attempts/oom-robustify
namely we are talking about 3c24392768ab ("vhost, mm: make sure that
oom_reaper doesn't reap memory read by vhost")
Thanks!
--
Michal Hocko
SUSE Labs
--
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>