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? Yes, if we dont't unmap its memory then vhost_worker() can't read the wrong zero from anonymous vma. But the killed process obviously won't be able to update this statefull info after that, it will be frozen. Are you saying this can't affect other apps which share the memory with the (killed) mm owner? IOW. If we kill a process, this can affect other applications anyway. Just for example, suppose that this process takes a non-robust futex in the shared memory segment. After that other users of this futex will hang forever. So do you think that this particular "vhost" problem is really worse and we must specialy avoid it? 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. 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>