On 07/11, Michal Hocko wrote: > > On Fri 08-07-16 14:29:48, Oleg Nesterov wrote: > > On 07/07, Michael S. Tsirkin wrote: > > > > > > On Thu, Jul 07, 2016 at 10:28:12AM +0200, Michal Hocko wrote: > > > > > > > > Just to make sure we are all at the same page. I guess the scenario is > > > > as follows. The owner of the mm has ring and other statefull information > > > > in the private memory but consumers living with their own mm consume > > > > some data from a shared memory segments (e.g. files). The worker would > > > > misinterpret statefull information (zeros rather than the original > > > > content) and would copy invalid/corrupted data to the consumer. Am I > > > > correct? > > > > > > Exactly. > > > > Michael, let me ask again. > > > > But what if we simply kill the owner of this mm? > > I might be wrong here but the mm owner doesn't really matter AFAIU. It > is the holder of the file descriptor for the "device" who control all > the actions, no? The fact that it hijacked the mm along the way is hiden > from users. If you kill the owner but pass the fd somewhere else then > the mm will live as long as the fd. Of course. I meant that qemu/guest won't update that statefull info in its anonymous memory after we kill it. And I have no idea if it is fine or not. As I said, I do not even know what drivers/vhost actually does, and probably that is why I do not understand why this particular problem (bogus zeroes in anonymous memory) is worse than other problems we can't avoid anyway when we kill the victim and this affects other applications. > > If yes, note that this means that any process which can do VHOST_SET_OWNER becomes > > "oom-unkillable" to some degree, and this doesn't look right. It can spawn another > > CLONE_FILES process and this will block fops->release() which (iiuc) should stop > > the kernel thread which pins the memory hog's memory. > > I believe this is indeed possible. It can even pass the fd to a > different process and keep it alive, hidden from the oom killer causing > other processes to be killed. Yes, so I think we should unmap the memory even if it is used by kthread. Oleg. -- 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>