On Sat, Dec 01, 2007 at 10:40:04PM +0900, YAMAMOTO Takashi wrote:
> > > is this uvm_map_pageable only for debug?
> > 
> > No, it's because we need to enter the mappings *now*, to be able to
> > report mappings that failed back to the ioctl caller.
> 
> hm, i didn't know that.
> 
> > > why do checkprot here?
> > 
> > To know if the va range was mapped read-only or read-write. Is there some
> > other way to get it ?
> 
> why bother to check it?

If the memory range was mmaped read-only I'm not sure we want to remap it
R/W at ioctl time. But it probably doesn't matter much.

> 
> > > please don't use uvm_unmap_remove and uvm_unmap_detach here.
> > > they are uvm-internal.
> > 
> > What would you suggect to use instead here ?
> 
> uvm_unmap without checkprot.  but see below.
> 
> > > besides, normally uvm_unmap_detach should not be used with the map locked.
> > > (it's the main reason why it's separated from uvm_unmap_remove.)
> > 
> > OK, that's easy :)
> > 
> > > 
> > > if the process is multithreaded (is xentools multithreaded?),
> > 
> > xentools is multithreaded, but I don't think this interface is going to
> > be used from multiple threads.
> 
> another thread does not need to use this interface.
> calling mmap is enough to interfere us.

OK. And we can't lock the map while doing the operation ...

> 
> > > you need to replace the mapping atomically.
> > > othewise the va range can be taken by another thread while we unmap it.
> > > uvm_map_replace does something similar, but it doesn't deal with
> > > arbitrary existing mappings.
> 
> i don't think it can be done without touching uvm internals currently.
> probably uvm_map can obtain a "replace existing mapping" flag.
> but i don't think it's worth to have.  i realy think it's better to fix
> the broken "replace anonymous mmap" interface.

I'm not sure how this would fix the issue. The ioctls would still be there,
and remplacing an existing mapping, be it anonymous or backed by an object
doesn't really change things.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--