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. [...] > 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. -- Michal Hocko SUSE Labs -- 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>