On Sat 13-08-16 03:15:00, Michael S. Tsirkin wrote:

On Fri, Aug 12, 2016 at 03:21:41PM +0200, Oleg Nesterov wrote:

quoted

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.

vhost thread will die, but vcpu thread is going on.  If it's memory is
corrupted because vhost read 0 and uses that as an array index, it can
do things like corrupt the disk, so it can't be restarted.

But I really wish we didn't need this special-casing.  Can't PTEs be
made invalid on oom instead of pointing them at the zero page?

Well ptes are just made !present and the subsequent #PF will allocate
a fresh new page which will be a zero page as the original content is
gone already. But I am not really sure what you mean by an invalid
pte. You are in a kernel thread context, aka unkillable context. How
would you handle SIGBUS or whatever other signal as a result of the
invalid access?

And then
won't memory accesses trigger pagefaults instead of returning 0?

See above. Zero page is just result of the lost memory content. We
cannot both reclaim and keep the original content.

That
would make regular copy_from_user machinery do the right thing,
making vhost stop running as appropriate.

I must be missing something here but how would you make the kernel
thread context find out the invalid access. You would have to perform
signal handling routine after every single memory access and I fail how
this is any different from a special copy_from_user_mm.
-- 
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>