Re: Nick's core remove PageReserved broke vmware...

[Hugh Dickins <hugh@veritas.com>]

On Thu, 3 Nov 2005, Michael S. Tsirkin wrote:
> Quoting Hugh Dickins <hugh@veritas.com>:
> > > All existing drivers that set VM_DONTCOPY also set VM_IO.
> > > So lets just disable playing with these flags from madvise if VM_IO is set.
> > > There's no reason I can see that the driver should have a say
> > > on what the process does with its own (non-IO) memory.
> > > Sounds good?
> > 
> > You're then saying that a process cannot set VM_DONTCOPY on a VM_IO
> > area to prevent the first child getting the area, but clear it after
> > so the next child does get a copy of the area.  I think it'd be wrong
> > (surprising) to limit the functionality in that way.
> 
> Okay, I guess. I am just trying to avoid more VM_ flags.
> Cant we get rid of the last requirement, then?

What last requirement?

> I dont see why the driver should have a say on what the process does with its
> own memory.

If a driver sets VM_DONTCOPY, it's likely to be because the driver knows
it'll cause some nastiness (memory corruption, memory leak, lockup...) if
it were copied.  The memory belongs to the driver, it's letting the process
have a window on it.  I don't think we should now let the process overrule it.

> > > By the way, as a separate issue, we still have a problem with DMA to pages
> > > which are *needed* by the child process. What do you think about VM_COPY
> > > (to do the old unix thing of actually copying the page instead of
> > > setting the COW flag) and a matching madvise call to set/clear it?
> > 
> > I don't much want to add another path into copy_pte_range, actually
> > copying pages.  If the process really wants DMA into such areas,
> > then it should contain the code for the child to COW them itself?
> 
> How do you do that, say, for a stack page, or global data section?

And why do you need to?

You seem to be saying, actually DONTCOPY isn't enough of a solution,
we need something else instead.

Hugh