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

[Michal Hocko <mhocko@kernel.org>]

On Mon 04-07-16 00:17:55, Michael S. Tsirkin wrote:
> On Sun, Jul 03, 2016 at 06:47:23PM +0200, Oleg Nesterov wrote:
> > On 07/03, Michael S. Tsirkin wrote:
> > >
> > > On Sun, Jul 03, 2016 at 05:18:29PM +0200, Oleg Nesterov wrote:
> > > >
> > > > Well, we are going to kill all tasks which share this memory. I mean, ->mm.
> > > > If "sharing memory with another task" means, say, a file, then this memory
> > > > won't be unmapped (if shared).
> > > >
> > > > So let me ask again... Suppose, say, QEMU does VHOST_SET_OWNER and then we
> > > > unmap its (anonymous/non-shared) memory. Who else's memory can be corrupted?
> > >
> > > As you say, I mean anyone who shares memory with QEMU through a file.
> > 
> > And in this case vhost_worker() reads the anonymous memory of QEMU process,
> > not the memory which can be shared with another task, correct?
> > 
> > And if QEMU simply crashes, this can't affect anyone who shares memory with
> > QEMU through a file, yes?
> > 
> > Oleg.
> 
> Well no - the VM memory is not always anonymous memory. It can be an
> mmaped file.

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?

-- 
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>