Re: Unifying /dev/{mem,kmem,zero,null} implementations

[Chris Gilbert <chris%dokein.co.uk@localhost>]

YAMAMOTO Takashi wrote:
> > Joerg Sonnenberger wrote:
> > > On Sun, Feb 24, 2008 at 12:40:51AM +0000, Chris Gilbert wrote:
> > > > The documentation says every pmap_kremove needs a pmap_update, relying on 
> > > > something later on doing a pmap_update is risky.
> > > Not here. The address is used strictly for one purpose and a CPU can
> > > only use it when holding the mutex. So the pmap_update after
> > > pmap_kremove shouldn't be needed.
> > >
> > > > In theory pmap_kremove could be optimised to not change anything in 
> > > > hardware, and defer the work to be done till the pmap_update, while I don't 
> > > > believe any platform has gone to that level yet, we shouldn't exclude the 
> > > > possibility by not following the documented API.
> > > I don't read the documentation that way. pmap_update will happen at a
> > > later point anyway and that should be good enough.
> > pmap(9) man page for pmap_update says:
> >
> > This routine must be used after calls to pmap_enter(), pmap_remove(), 
> > pmap_protect(), pmap_kenter_pa(), and pmap_kremove() in order to ensure 
> > correct operation of the virtual memory system.
>
> it doesn't say "immediately after".

You're right it doesn't, I guess it depends what the expectation is.

I'd have expected pmap_update to happen soon after the pmap_* call, 
generally within the calling function.  The same as all other uses of 
pmap_update.

Perhaps I'm just being overly paranoid, and worried that something 
somewhere will allow a memory access it shouldn't rather than causing a 
trap or access fault.

Thanks,
Chris