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

[Michal Hocko <mhocko@kernel.org>]

On Mon 15-08-16 11:49:12, Michal Hocko wrote:
> On Mon 15-08-16 02:06:31, Michael S. Tsirkin wrote:
> [...]
> > So fundamentally, won't the following make copy to/from user
> > return EFAULT?  If yes, vhost is already prepared to handle that.
> > 
> > 
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index dc80230..e5dbee5 100644
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -1309,6 +1309,11 @@ retry:
> >  		might_sleep();
> >  	}
> >  
> > +	if (unlikely(test_bit(MMF_UNSTABLE, &mm->flags))) {
> > +		bad_area(regs, error_code, address);
> > +		return;
> > +	}
> > +
> >  	vma = find_vma(mm, address);
> >  	if (unlikely(!vma)) {
> >  		bad_area(regs, error_code, address);
> 
> This would be racy but even if we did the check _after_ the #PF is
> handled then I am not very happy to touch the #PF path which is quite
> hot for something as rare as OOM and which only has one user which needs
> a special handling. That is the primary reason why I prefer the specific
> API.

I would really appreciate if we could reach some conclusion here. I
would like to target the upcoming merge window. I do not insist on the
approach I have taken but I feel it is the least disruptive wrt. the
usecase. If there is a strong opposition and a general agreement that
hooking into the page fault handler is a better way to go I can
implement that. But please consider the amount of work and the fact that
it is only vhost which really matters here.
-- 
Michal Hocko
SUSE Labs

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