Thread (47 messages) 47 messages, 5 authors, 2016-08-24

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

From: Michal Hocko <mhocko@kernel.org>
Date: 2016-08-12 14:42:01

On Fri 12-08-16 15:21:41, Oleg Nesterov wrote:
On 08/12, Michal Hocko wrote:
[...]
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.
All the threads should be killed/exiting so they shouldn't access that
memory. My assumption is that the exit path doesn't touch that memory.
If any of threads was in the middle of the page fault or g-u-p while
writing to that address then it should be OK because it would be just
a matter of SIGKILL timing.  I might be wrong here and in that case
__get_user_mm wouldn't be sufficient of course.
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.
Yes, I admit that I am not familiar with the vhost memory usage model so
I can only speculate. But the mere fact that the mm is bound to a device
fd which can be passed over to a different process makes me worried.
This means that the mm is basically isolated from the original process
until the last fd is closed which is under control of the process which
holds it. The mm can still be access during that time from the vhost
worker. And I guess this is exactly where the problem lies.
-- 
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help